Marc Dietrich
2015-Feb-16 09:39 UTC
[LLVMdev] [Mesa-dev] mesa-10.4.4: BROKEN TLS support in GLXwith llvm-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 isabout 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 externsymbols, 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>
Marc Dietrich
2015-Feb-16 11:45 UTC
[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 pointsno 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>
Seemingly Similar Threads
- [LLVMdev] [Mesa-dev] mesa-10.4.4: BROKEN TLS support in GLXwith llvm-toolchain v3.6.0rc2
- [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
- [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
- [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
- [LLVMdev] [PATCH 0/2 v3] add visibility hidden to tls entry points