llvm dev - Feb 2015 - [LLVMdev] [Mesa-dev] mesa-10.4.4: BROKEN TLS support in GLXwithllvm-toolchain v3.6.0rc2

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-src_
> >> >>> _ma
> >> >>> pi__entry_x86-64_tls.h?view=markup
> >> >>>
https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src_
> >> >>> _m
> >> >>> api__entry_x86_tls.h?view=markup
> >> >>>
https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src_
> >> >>> _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.

Marc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/f275d7b1/attachment.sig>

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-src_
>> >> >>> _ma
>> >> >>> pi__entry_x86-64_tls.h?view=markup
>> >> >>>
https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src_
>> >> >>> _m
>> >> >>> api__entry_x86_tls.h?view=markup
>> >> >>>
https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src_
>> >> >>> _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.

Thanks.

- Sedat -

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

Marc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/22892d5b/attachment.sig>