[Mesa-dev] [LLVMdev] mesa-10.4.4: BROKEN TLS support inGLXwithllvm-toolchain v3.6.0rc2

[Sedat Dilek]

On Tue, Feb 17, 2015 at 10:12 AM, Marc Dietrich <marvin24 at gmx.de> wrote:
> Am Dienstag, 17. Februar 2015, 10:05:33 schrieb Sedat Dilek:
>> On Mon, Feb 16, 2015 at 12:45 PM, Marc Dietrich <marvin24 at gmx.de> wrote:
>> > Am Montag, 16. Februar 2015, 12:42:19 schrieb Sedat Dilek:
>> >> On Mon, Feb 16, 2015 at 10:39 AM, Marc Dietrich <marvin24 at gmx.de> wrote:
>> >> > Am Samstag, 14. Februar 2015, 18:20:12 schrieb Dimitry Andric:
>> >> >> On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>> >> >> > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov
>> >> >> > <emil.l.velikov at gmail.com>
>> >> >
>> >> > wrote:
>> >> >> >> On 10/02/15 13:17, Dimitry Andric wrote:
>> >> >> >>> On 09 Feb 2015, at 18:52, Sedat Dilek <sedat.dilek at gmail.com>
> wrote:
>> >> >> >>>> On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov
>> >> >> >>>> <emil.l.velikov at gmail.com>
>> >> >
>> >> > wrote:
>> >> >> >>>>> On 07/02/15 22:42, Sedat Dilek wrote:
>> >> >> >>> ...
>> >> >> >>>
>> >> >> >>>>>> In file included from ../../src/mapi/entry.c:49:
>> >> >> >>>>>> ./entry_x86-64_tls.h:66:1: warning: tentative array definition
>> >> >> >>>>>> assumed
>> >> >> >>>>>> to have one element
>> >> >> >>>>>> x86_64_entry_start[];
>> >> >> >>>>>> ^
>> >> >> >>>>>> fatal error: error in backend: symbol 'x86_64_entry_start' is
>> >> >> >>>>>> already
>> >> >> >>>>>> defined>>>
>> >> >> >>>
>> >> >> >>> ...
>> >> >> >>>
>> >> >> >>>>> It may be that it's a bug on our end, but it's a bit painful
>> >> >> >>>>> going
>> >> >> >>>>> through all the auto generated sources, the 10+ define guards
>> >> >> >>>>> and
>> >> >> >>>>> other
>> >> >> >>>>> magic that's inside src/mapi. Getting some idea on llvm/clang
>> >> >> >>>>> behaviour
>> >> >> >>>>> change should help out :-)
>> >> >> >>>>>
>> >> >> >>>>> Please open a bug-report with llvm and/or mesa, so that we have
>> >> >> >>>>> all
>> >> >> >>>>> the
>> >> >> >>>>> info in one place and things don't get lost.
>> >> >> >>>>
>> >> >> >>>> I am unsure if it is a bug in llvm/clang or in mesa.
>> >> >> >>>> Shall I open 2 bug-reports - in mesa and llvm BTS?
>> >> >> >>>
>> >> >> >>> Please have a look at this PR, which I opened in May 2014, and
>> >> >> >>> which
>> >> >> >>> is
>> >> >
>> >> > about the same issue:
>> >> >> >>>  http://llvm.org/PR19778
>> >> >> >>
>> >> >> >> Hi Dimitry,
>> >> >> >>
>> >> >> >> From a quick look at the bug, the llvm/clang devs are quoting the
>> >> >> >> C11
>> >> >> >> spec, yet we're not building with -std=c11 so I'm not sure that
>> >> >> >> applies.
>> >> >> >> Feel free to forward that if interested - I'm a bit short on
>> >> >> >> account
>> >> >> >> on
>> >> >> >> their bugzilla :-)
>> >> >> >>
>> >> >> >>> The assertion seems to have been transformed now into a backend
>> >> >> >>> error,
>> >> >> >>> but this may also be because you built clang without assertions.
>> >> >> >>> (Did
>> >> >> >>> you?)>>>
>> >> >> >>> In any case, the workaround is to change the static symbols into
>> >> >> >>> extern
>> >> >
>> >> > symbols, together with a hidden visibility attribute (as suggested by
>> >> > Rafael>
>> >> >
>> >> > Espíndola), similar to the fix I posted in this FreeBSD port bug:
>> >> >> >>>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192286
>> >> >> >>>
>> >> >> >>> E.g., you can use these patches:
>> >> >> >>>
>> >> >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-s
>> >> >> >>> rc_
>> >> >> >>> _ma
>> >> >> >>> pi__entry_x86-64_tls.h?view=markup
>> >> >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-s
>> >> >> >>> rc_
>> >> >> >>> _m
>> >> >> >>> api__entry_x86_tls.h?view=markup
>> >> >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-s
>> >> >> >>> rc_
>> >> >> >>> _m
>> >> >> >>> api__entry_x86_tsd.h?view=markup>>
>> >> >> >>
>> >> >> >> These patches don't look at all bad. Can you give them a bit of TLS
>> >> >> >> and
>> >> >> >> send them to the list, please ? This also stands for the other
>> >> >> >> patches
>> >> >> >> in FreeBSD's repo :-)
>> >> >> >
>> >> >> > On the one hand I am glad to see that there are patches available.
>> >> >> > I will give them a try when I am at home.
>> >> >> > On the other hand - knowing FreeBSD switched to llvm/clang as
>> >> >> > default-compiler - it's abit pity to see that stuff like this is not
>> >> >> > shared with upstream (did not look at the date of submission).
>> >> >> > If you have more patches in this area, please share them with
>> >> >> > upstream.
>> >> >>
>> >> >> The complete collection is here:
>> >> >>
>> >> >> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/
>> >> >>
>> >> >> I didn't create most of these patches, so I can't really say what the
>> >> >> reason for them was, or whether they still apply to Mesa master.
>> >> >>
>> >> >> In any case, for this specific issue with Mesa's TLS related
>> >> >> definitions
>> >> >> breaking clang, please consider the attached patch.
>> >> >
>> >> > I think there is no need to restrict this to clang only as it also
>> >> > works
>> >> > with gcc. I submitted a slightly different version to the mesa list
>> >> > which
>> >> > uses a macro instead and also adds some credits.
>> >>
>> >> Sorry for the late response... troubles with my Internet connection.
>> >>
>> >> Those two patches or do I need more?
>> >>
>> >> [PATCH 1/4] configure: add visibility macro detection to configure
>> >> [PATCH 2/4] add visibility hidden to tls entry points
>> >
>> > no that's all, sorry I still have two unrelated patches in my HEAD. So
>> > this
>> > should actually have been /2.
>>
>> Hehe.
>>
>> I haven't had the time to test them.
>> ( Still doing all my OS updates with UMTS/HSPA. )
>>
>> Can you send a new v2 with only those two patches?
>> Maybe together with a git-cover-letter?
>> To all involved people here for easier review.
>
> I'll send a new V3 soon because I forgot a change in V2.
>
> Thanks
>

In German we say: "Alle guten Dinge sind 3." :-)

- Sedat -