On 6/6/2016 9:27 AM, Jon Turney wrote:
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...
For the record, Jon seems to have tracked this down, and his fix is in
llvm-3.7.1-2. I can only imagine what "fun" he had debugging this,
particularly on the address-starved 32-bit platform.
Andrew, could you please do the honours?
--
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
