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

Tue Feb 17 03:55:18 PST 2015

On Tue, Feb 17, 2015 at 12:36 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> 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)?
>

Adding "-fPIC" to my {C,CXX}FLAGS seems to fix this.

>From my v2 build-script:
...
export CC="clang -v"
export CFLAGS="-Qunused-arguments -fPIC"
export CXX="clang++"
export CXXFLAGS="$CFLAGS"
export CPP="clang-cpp"
export CPPFLAGS="-I$PREFIX/include"
...

- Sedat -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_mesa-with-llvm-v2.sh
Type: application/x-sh
Size: 4110 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150217/875c92ae/attachment-0001.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build-and-install-log_mesa-10-4-4_llvm-3-6-0-rc2_gallivm-fixes_clang-fixes-freebsd_enable-glx-tls_fPIC.txt.gz
Type: application/x-gzip
Size: 85255 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150217/875c92ae/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build-and-install-log_mesa-10-4-4_llvm-3-6-0-rc2_gallivm-fixes_clang-fixes-freebsd_enable-glx-tls_fPIC.txt.gz.sha256sum
Type: application/octet-stream
Size: 176 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150217/875c92ae/attachment-0001.obj>