[Mesa-dev] [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2

Tue Feb 17 03:36:54 PST 2015

On Sat, Feb 14, 2015 at 6:20 PM, Dimitry Andric <dimitry at andric.com> wrote:
> 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__mapi__entry_x86-64_tls.h?view=markup
>>>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__mapi__entry_x86_tls.h?view=markup
>>>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__mapi__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.
>

Applying an adapted version to fit mesa v10.4.4 causes the following errors:

...
make[4]: Entering directory `/home/wearefam/src/mesa/mesa-git/src/mapi'
  CCLD   shared-glapi/libglapi.la
clang version 3.6.0 (tags/RELEASE_360/rc2)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m
elf_x86_64 -shared -o shared-glapi/.libs/libglapi.so.0.0.0
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginS.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.9
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../..
-L/opt/llvm-toolchain-3.6.0rc2/bin/../lib -L/lib -L/usr/lib
.libs/shared_glapi_libglapi_la-entry.o
.libs/shared_glapi_libglapi_la-mapi_glapi.o
.libs/shared_glapi_libglapi_la-stub.o
.libs/shared_glapi_libglapi_la-table.o
.libs/shared_glapi_libglapi_la-u_current.o
.libs/shared_glapi_libglapi_la-u_execmem.o -lpthread
/usr/lib/x86_64-linux-gnu/libexpat.so --gc-sections --no-undefined
-soname libglapi.so.0 -lgcc --as-needed -lgcc_s --no-as-needed
-lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: .libs/shared_glapi_libglapi_la-entry.o: relocation
R_X86_64_32S against `.rodata' can not be used when making a shared
object; recompile with -fPIC
.libs/shared_glapi_libglapi_la-entry.o: could not read symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [shared-glapi/libglapi.la] Error 1
make[4]: Leaving directory `/home/wearefam/src/mesa/mesa-git/src/mapi'

Can you look at this (see also attached tarball)?

- Sedat -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: for-andric.tar.gz
Type: application/x-gzip
Size: 11061 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150217/73d1af66/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: for-andric.tar.gz.sha256sum
Type: application/octet-stream
Size: 84 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150217/73d1af66/attachment-0001.obj>