mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2

Project Infrastructure LLVM Dev List Archives
1

[ 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=\"Bugzilla Main Page;
-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:

build-and-install-log_mesa-10-4-4_llvm-3-6-0-rc2_gallivm-fixes_enable-glx-tls_clang-v_make-j-1.txt (42.4 KB)

entry-f26a8a.c (1.62 MB)

entry-f26a8a.sh (2.14 KB)

build_mesa-with-llvm.sh (4.01 KB)

2

Just as a hint:

You need to cherry-pick...

commit ef7e0b39a24966526b102643523feac765771842
"gallivm: Update for RTDyldMemoryManager becoming an unique_ptr."

...from mesa upstream to build v10.4.4 successfully.

- Sedat -

3

I think we decided not to support unreleased LLVM builds on stable releases.

This is because building without errors is not enough -- there are often other changes that need to go with this. Furthermore it's often a moving target.

In short, if you want to use bleeding edge LLVM, you must use bleeding edge Mesa too.

What I think it might be worthwhile to do is have a ceiling on the maximum supported LLVM version on a stable branch. That is, fail configure if the user attempts to build with a LLVM that's too new.

Jose

4

I think we decided not to support unreleased LLVM builds on stable releases.

This is because building without errors is not enough -- there are often
other changes that need to go with this. Furthermore it's often a moving
target.

In short, if you want to use bleeding edge LLVM, you must use bleeding edge
Mesa too.

What I think it might be worthwhile to do is have a ceiling on the maximum
supported LLVM version on a stable branch. That is, fail configure if the
user attempts to build with a LLVM that's too new.

Yeah, that's why I moved from mesa-10.3 to mesa-10.4.

I am aware of the risks using "bleeding-edge" software.
As said... for me it is a "field-test" and come on LLVM/Clang v3.6.0
is "soonish" released :-).

Thanks that you catched and fixed so many LLVM 3.6 bugs in mesa!

- Sedat -

5

Hi Sedat,

[ 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=\"Bugzilla Main Page;
-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 :slight_smile:

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.

Thanks
Emil

6

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 -

7

Hi Sedat,

[ 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=\"Bugzilla Main Page \""
-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 "."
#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
Bugzilla Main Page 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.

This is an issue with building Mesa with Clang, but I actually don't have much experience with that. (I mostly use LLVM as a JIT library.)

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 :slight_smile:

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.

Thanks
Emil

Yeah, the mapi/glapi code is a bit sensitive -- there are several possible configurations (assembly, no assembly, shared glapi, etc.) -- they all produce slightly different machine code.

Jose

8

When you say assembly... where can I pass elegantly "-no-integrated-as"?
Globally in CFLAGS | CXXFLAGS | LDFLAGS?
In src/mapi/Makefile.am only? E.g. in shared_glapi_libglapi_la_LDFLAGS?

- Sedat -

9

./configure --disable-asm should do it. But as I said, I rarely use autoconf

Jose

10

...

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 :slight_smile:

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:

  192286 – [PATCH] graphics/libGL: fix build with clang

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

11

...

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 :slight_smile:

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 :slight_smile:

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:

  192286 – [PATCH] graphics/libGL: fix build with clang

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 :slight_smile:

Thanks
Emil

12

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.

Thanks.

- Sedat -

13

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.

-Dimitry

fix-clang-double-symbol-1.diff (1.73 KB)

14

>>> ...
>>>
>>>>>> 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
>>>>>> >>>
>>> ...
>>>
>>>>> 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 :slight_smile:
>>>>>
>>>>> 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 :slight_smile:
>>
>>> 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:

>>> 192286 – [PATCH] graphics/libGL: fix build with clang
>>>
>>> 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 :slight_smile:
>
> 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

15

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

Regards,
- Sedat -

[1] [Mesa-dev] [PATCH 1/4] configure: add visibility macro detection to configure
[2] [Mesa-dev] [PATCH 2/4] add visibility hidden to tls entry points

16

no that's all, sorry I still have two unrelated patches in my HEAD. So this
should actually have been /2.

Marc

17

Hehe.

I haven't had the time to test them.
( Still doing all my OS updates with UMTS/HSPA. )

Can you send a new v2 with only those two patches?
Maybe together with a git-cover-letter?
To all involved people here for easier review.

Thanks.

- Sedat -

18

I'll send a new V3 soon because I forgot a change in V2.

Thanks

Marc

19

In German we say: "Alle guten Dinge sind 3." :slight_smile:

- Sedat -

20

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 -

for-andric.tar.gz (10.8 KB)

for-andric.tar.gz.sha256sum (84 Bytes)