[ANNOUNCEMENT] mesa 11.0.9-2 [GOLDSTAR]

Thu Jun 9 22:01:00 GMT 2016

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 0ドルx10,0x4(%eax,%edi,1),%xmm0
>>>>> 0x7fdf00b9: insertps 0ドルx20,0x8(%eax,%edi,1),%xmm0
>>>>> => 0x7fdf00c1: insertps 0ドルx30,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