On 06/06/2016 08:24, Yaakov Selkowitz wrote:
On 2016-06-03 12:56, Jon Turney wrote:
On 31/05/2016 18:03, Jon Turney wrote:
# gdb ./quad-clip
[...]
(gdb) r
[...]
Program received signal SIGSEGV, Segmentation fault.
0x7fdf00c1 in ?? ()
[...]
/usr/src/debug/mesa-demos-8.3.0-1/src/trivial/quad-clip.c:137
(gdb) disassemble 0x7fdf00b1,0x7fdf00d2
Dump of assembler code from 0x7fdf00b1 to 0x7fdf00d2:
0x7fdf00b1: insertps $0x10,0x4(%eax,%edi,1),%xmm0
0x7fdf00b9: insertps $0x20,0x8(%eax,%edi,1),%xmm0
=> 0x7fdf00c1: insertps $0x30,0xfffeff34,%xmm0
0x7fdf00cb: mov (%esi),%eax
0x7fdf00cd: mul %ecx
After staring this a bit more, I see that this is the offset to the data
to load, apparently being used as an absolute address
This seems to be the case with other addresses in the JIT-ed code, so
perhaps there is some problem preventing relocations being applied...
FWIW, I tried rebuilding with llvm 3.8.0. 32-bit doesn't crash anymore,
and glxgears says its running, but only the background shows.
Thanks, that was next on my list to try
That sounds exactly like what I see with llvm svn r251761 [1] backported
to 3.7.1 (without which we use the x86_64 loader on x86, rather than
reporting an error, due to an interesting use of __builtin_undefined,
with hilarious consequences)
I guess the output of the JIT code is ending up the wrong place as well,
or something...