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

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.

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/de17f5cd/attachment.sig>

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>