Sedat Dilek
2015-Feb-09 17:52 UTC
[LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:> Hi Sedat, > > On 07/02/15 22:42, Sedat Dilek wrote: >> [ Please CC me I am not subscribed to mesa-dev and llvmdev MLs ] >> >> Hi, >> >> I already reported this when playing 1st time with my llvm-toolchain >> v3.6.0rc2 and mesa v10.3.7 [1]. >> The issue still remains in mesa v10.4.4. >> >> So, this is a field test to see if LLVM/Clang v3.6.0rc2 fits my needs. >> >> I see the following build-error... >> ... >> >> make[4]: Entering directory `/home/wearefam/src/mesa/mesa-git/src/mapi' >> CC shared_glapi_libglapi_la-entry.lo >> 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 >> "/opt/llvm-toolchain-3.6.0rc2/bin/clang" -cc1 -triple >> x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free >> -main-file-name entry.c -mrelocation-model static -mthread-model posix >> -mdisable-fp-elim -relaxed-aliasing -fmath-errno -masm-verbose >> -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu >> x86-64 -target-linker-version 2.22 -v -g -dwarf-column-info >> -coverage-file /home/wearefam/src/mesa/mesa-git/src/mapi/entry.c >> -resource-dir /opt/llvm-toolchain-3.6.0rc2/bin/../lib/clang/3.6.0 >> -dependency-file .deps/shared_glapi_libglapi_la-entry.Tpo >> -sys-header-deps -MP -MT shared_glapi_libglapi_la-entry.lo -D >> "PACKAGE_NAME=\"Mesa\"" -D "PACKAGE_TARNAME=\"mesa\"" -D >> "PACKAGE_VERSION=\"10.4.4\"" -D "PACKAGE_STRING=\"Mesa 10.4.4\"" -D >> "PACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\"" >> -D "PACKAGE_URL=\"\"" -D "PACKAGE=\"mesa\"" -D "VERSION=\"10.4.4\"" -D >> STDC_HEADERS=1 -D HAVE_SYS_TYPES_H=1 -D HAVE_SYS_STAT_H=1 -D >> HAVE_STDLIB_H=1 -D HAVE_STRING_H=1 -D HAVE_MEMORY_H=1 -D >> HAVE_STRINGS_H=1 -D HAVE_INTTYPES_H=1 -D HAVE_STDINT_H=1 -D >> HAVE_UNISTD_H=1 -D HAVE_DLFCN_H=1 -D "LT_OBJDIR=\".libs/\"" -D >> YYTEXT_POINTER=1 -D HAVE___BUILTIN_BSWAP32=1 -D >> HAVE___BUILTIN_BSWAP64=1 -D HAVE___BUILTIN_CLZ=1 -D >> HAVE___BUILTIN_CLZLL=1 -D HAVE___BUILTIN_CTZ=1 -D >> HAVE___BUILTIN_EXPECT=1 -D HAVE___BUILTIN_FFS=1 -D >> HAVE___BUILTIN_FFSLL=1 -D HAVE___BUILTIN_POPCOUNT=1 -D >> HAVE___BUILTIN_POPCOUNTLL=1 -D HAVE___BUILTIN_UNREACHABLE=1 -D >> HAVE_DLADDR=1 -D HAVE_PTHREAD=1 -D HAVE_LIBEXPAT=1 -D >> USE_EXTERNAL_DXTN_LIB=1 -D _GNU_SOURCE -D USE_SSE41 -D DEBUG -D >> USE_X86_64_ASM -D HAVE_XLOCALE_H -D HAVE_STRTOF -D HAVE_DLOPEN -D >> HAVE_POSIX_MEMALIGN -D HAVE_LIBDRM -D GLX_USE_DRM -D HAVE_LIBUDEV -D >> GLX_INDIRECT_RENDERING -D GLX_DIRECT_RENDERING -D GLX_USE_TLS -D >> HAVE_ALIAS -D HAVE_MINCORE -D HAVE_LLVM=0x0306 -D LLVM_VERSION_PATCH=0 >> -D MAPI_MODE_GLAPI -D >> "MAPI_ABI_HEADER=\"shared-glapi/glapi_mapi_tmp.h\"" -I . -I >> ../../include -I ../../src/mapi -I ../../src/mapi -I /opt/xorg/include >> -internal-isystem /usr/local/include -internal-isystem >> /opt/llvm-toolchain-3.6.0rc2/bin/../lib/clang/3.6.0/include >> -internal-externc-isystem /usr/include/x86_64-linux-gnu >> -internal-externc-isystem /include -internal-externc-isystem >> /usr/include -O0 -Wall -Werror=implicit-function-declaration >> -Werror=missing-prototypes -std=c99 -fdebug-compilation-dir >> /home/wearefam/src/mesa/mesa-git/src/mapi -ferror-limit 19 >> -fmessage-length 0 -pthread -mstackrealign -fobjc-runtime=gcc >> -fdiagnostics-show-option -o entry.o -x c ../../src/mapi/entry.c >> clang -cc1 version 3.6.0 based upon LLVM 3.6.0 default target >> x86_64-unknown-linux-gnu >> ignoring nonexistent directory "/include" >> ignoring duplicate directory "." >> ignoring duplicate directory "." >> #include "..." search starts here: >> #include <...> search starts here: >> . >> ../../include >> /opt/xorg/include >> /usr/local/include >> /opt/llvm-toolchain-3.6.0rc2/bin/../lib/clang/3.6.0/include >> /usr/include/x86_64-linux-gnu >> /usr/include >> End of search list. >> 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 >> clang: error: clang frontend command failed with exit code 70 (use -v >> to see invocation) >> clang version 3.6.0 (tags/RELEASE_360/rc2) >> Target: x86_64-unknown-linux-gnu >> Thread model: posix >> clang: note: diagnostic msg: PLEASE submit a bug report to >> http://llvm.org/bugs/ and include the crash backtrace, preprocessed >> source, and associated run script. >> clang: note: diagnostic msg: >> ******************** >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> Preprocessed source(s) and associated run script(s) are located at: >> clang: note: diagnostic msg: /tmp/entry-f26a8a.c >> clang: note: diagnostic msg: /tmp/entry-f26a8a.sh >> clang: note: diagnostic msg: >> >> ******************** >> make[4]: *** [shared_glapi_libglapi_la-entry.lo] Error 1 >> make[4]: Leaving directory `/home/wearefam/src/mesa/mesa-git/src/mapi' >> make[3]: *** [all-recursive] Error 1 >> make[3]: Leaving directory `/home/wearefam/src/mesa/mesa-git/src/mapi' >> make[2]: *** [all] Error 2 >> make[2]: Leaving directory `/home/wearefam/src/mesa/mesa-git/src/mapi' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/home/wearefam/src/mesa/mesa-git/src' >> make: *** [all-recursive] Error 1 >> Command exited with non-zero status 2 >> ... >> >> I have attached my build-script, the detailed full build-log (used >> 'clang -v' and 'make -j1') and the two diagnostic tmp-files. >> >> I am not sure if this is fixable in mesa by refactoring the code - >> that's why I CCed especially Jose. >> >> If it's a llvm/clang bug, so the folks there should look. >> >> If you need more informations, please let me know. >> > Perhaps getting some (rough) idea of the commit this started failing is > a nice start. Currently mapi is built in 3-4 different "modes", and it > builds fine with gcc/msvc. > > 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? - Sedat -
Dimitry Andric
2015-Feb-10 13:17 UTC
[LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
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 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 -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150210/fbcb2d6d/attachment.sig>
Emil Velikov
2015-Feb-10 23:09 UTC
[LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
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 C11spec, 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 :-) Thanks Emil