Looks like maybe libglapi.so.0 should be picked up from somewhere other than /usr/libx32/libglapi.so.0? It should be from the same build as the rest of the Mesa binaries. If that's not the problem, please get a backtrace with debugging symbols available for /usr/libx32/libglapi.so.0 as well.

(In reply to Michel Dänzer from comment #1)
> Looks like maybe libglapi.so.0 should be picked up from somewhere other than
> /usr/libx32/libglapi.so.0? It should be from the same build as the rest of
> the Mesa binaries. If that's not the problem, please get a backtrace with
> debugging symbols available for /usr/libx32/libglapi.so.0 as well.

I am not sure where it should be picked up from. How would I figure that out?

The library is from the same build as the rest of the Mesa binaries and the library has debugging symbols available.

/usr/libx32/libglapi.so:           symbolic link to libglapi.so.0.0.0
/usr/libx32/libglapi.so.0:         symbolic link to libglapi.so.0.0.0
/usr/libx32/libglapi.so.0.0.0:     ELF 32-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

This segfault is not restricted to starting X, but also happen with glxgears and glxinfo in a multilib environment.


I also figured out those segfaults only happen if glx-tls is enabled. If glx-tls is disabled X, glxinfo and glxgears work fine again.

Sounds like it's not a driver specific issue then but a general one with GLX-TLS on x32.

(In reply to Michel Dänzer from comment #4)
> Sounds like it's not a driver specific issue then but a general one with
> GLX-TLS on x32.

X did not segfault when I used my Barts (radeon + r600) instead of the Tonga (amdgpu + radeonsi), although I had no acceleration on both. So there might be too issues here which I mixed up by accident. I'll stick to the glx-tls issue from now on.

Based of the backtrace there is no information if mesa/libglapi was build with or w/o glx-tls. Following an IRC conversation it seems that the library is built w/o glx-tls as i is missing the _glapi_tls_Context and _glapi_tls_Dispatch symbols.

Perhaps they are different builds ? Either way it's good to attach the output of $nm -CD --defined-only /usr/libx32/libglapi.so in this particular case.

Also please that the correct libraries are being picked up. This can be done via something like:
 $LD_DEBUG=libs foo (startx) 2>ld_debug.log

Obviously none of these excludes that there is an actual issue with x32 and glx-tls and/or that mesa silently ignores the flag on said platform ;-)

Created attachment 124376 [details]
LD_DEBUG=libs startx

(In reply to Emil Velikov from comment #6)
> Based of the backtrace there is no information if mesa/libglapi was build
> with or w/o glx-tls. Following an IRC conversation it seems that the library
> is built w/o glx-tls as i is missing the _glapi_tls_Context and
> _glapi_tls_Dispatch symbols.
> 
> Perhaps they are different builds ? Either way it's good to attach the
> output of $nm -CD --defined-only /usr/libx32/libglapi.so in this particular
> case.
> 
> Also please that the correct libraries are being picked up. This can be done
> via something like:
>  $LD_DEBUG=libs foo (startx) 2>ld_debug.log
> 
> Obviously none of these excludes that there is an actual issue with x32 and
> glx-tls and/or that mesa silently ignores the flag on said platform ;-)

glx-tls never worked for me on my x32 setup. This setup is only around half a year old, so I don't know if it worked before.

$ nm -CD --defined-only /usr/libx32/libglapi.so
00000004 B _glapi_tls_Context
00000000 D _glapi_tls_Dispatch
In full: https://gist.github.com/anonymous/543fd6a51163ced35819df49dbd0902c

Double-checking the logs - seems like TLS is built/used throughout the board.
One thing which comes to mind - can you try with --disable-asm. I'm fairly sure that the code we have in there doesn't attribute x32.

Note: I'll be pushing a patch which makes --enable-glx-tls the default in a moment, so please keep it disabled locally until we get to the bottom of this.

(In reply to Emil Velikov from comment #8)
> Double-checking the logs - seems like TLS is built/used throughout the board.
> One thing which comes to mind - can you try with --disable-asm. I'm fairly
> sure that the code we have in there doesn't attribute x32.
> 
> Note: I'll be pushing a patch which makes --enable-glx-tls the default in a
> moment, so please keep it disabled locally until we get to the bottom of
> this.

I can confirm that a "--enable-glx-tls --disable-asm" works as well as "--disable-glx-tls --enable-asm".

Created attachment 128810 [details] [review]
x32 fix attempt

Maybe this patch will help?

If not, any tips how to set up a x32 environment without spending the whole day on it? My distro is Ubuntu.

Ignore the previous patch, it's botched.
I've compiled the x32 deps, so could test what allowed to produce a working patch:
https://lists.freedesktop.org/archives/mesa-dev/2017-January/139946.html

(In reply to Grazvydas Ignotas from comment #11)
> Ignore the previous patch, it's botched.
> I've compiled the x32 deps, so could test what allowed to produce a working
> patch:
> https://lists.freedesktop.org/archives/mesa-dev/2017-January/139946.html

I tried both patches and only the one on the ML is working.

I am no expert, but don't you want to use exact-length types instead of "long long"?

(In reply to EoD from comment #12)
> I am no expert, but don't you want to use exact-length types instead of
> "long long"?

mapi doesn't use such types and I did not want to drag in a dependency. Also the modified file is for x86-64 only and has asm in GNU syntax, anything compiling that should have long long of 8 bytes.

Fixed by

commit 89458366585c34879b70110758bb4fd3acb62ce0
Author: Grazvydas Ignotas <notasas@gmail.com>
Date:   Sun Jan 8 19:38:09 2017 +0200

    mapi: update the asm code to support x32

Thanks Grazvydas!