[ANNOUNCEMENT] mesa 11.0.9-2

[ANNOUNCEMENT] mesa 11.0.9-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* mesa-11.0.9-2
* dri-drivers-11.0.9-2
* libglapi0-11.0.9-2
* libGL1-11.0.9-2
* libGL-devel-11.0.9-2
* libOSMesa8-11.0.9-2
* libOSMesa-devel-11.0.9-2
* libEGL1-11.0.9-2
* libEGL-devel-11.0.9-2
* libGLESv2_2-11.0.9-2
* libGLESv2-devel-11.0.9-2
* windowsdriproto-11.0.9-2

Mesa is an open-source implementation of the OpenGL specification, a system 
for rendering interactive 3D graphics.

Complete documentation on OpenGL usage and configuration can be found here:

http://x.cygwin.com/docs/ug/using-glx.html

This release has been rebuilt for LLVM 3.7.

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

Re: [ANNOUNCEMENT] mesa 11.0.9-2

[Marco Atzeri]

On 22/02/2016 10:00, Yaakov Selkowitz wrote:
> The following packages have been uploaded to the Cygwin distribution:
>
> * mesa-11.0.9-2
> * dri-drivers-11.0.9-2
> * libglapi0-11.0.9-2
> * libGL1-11.0.9-2
> * libGL-devel-11.0.9-2
> * libOSMesa8-11.0.9-2
> * libOSMesa-devel-11.0.9-2
> * libEGL1-11.0.9-2
> * libEGL-devel-11.0.9-2
> * libGLESv2_2-11.0.9-2
> * libGLESv2-devel-11.0.9-2
> * windowsdriproto-11.0.9-2
>
> Mesa is an open-source implementation of the OpenGL specification, a system
> for rendering interactive 3D graphics.
>
> Complete documentation on OpenGL usage and configuration can be found here:
>
> http://x.cygwin.com/docs/ug/using-glx.html
>
> This release has been rebuilt for LLVM 3.7.
>
> --
> Yaakov
>

Hi Yaakov,
we found a case where the 32bit is segfaulting
while dri-drivers-11.0.9-1
works fine.
For reference:
https://cygwin.com/ml/cygwin/2016-04/msg00245.html
https://cygwin.com/ml/cygwin/2016-04/msg00251.html

To replicate with octave is enough :
run from xterm
   /usr/bin/octave-cli-4.0.1.exe

  x=1:100;
  plot(x,x)

as dri-drivers seems absent from mesa-debuginfo
I can not provide you a meaningful backtrace:

#0  0xfc6d00a0 in ?? ()
#1  0x43934357 in gallium_dri!__driDriverGetExtensions_swrast ()
    from E:/cygwin/lib/dri/swrast_dri.so
#2  0x439346c6 in gallium_dri!__driDriverGetExtensions_swrast ()
    from E:/cygwin/lib/dri/swrast_dri.so
...
#12 0x43563ce9 in gallium_dri!__driDriverGetExtensions_swrast ()
    from E:/cygwin/lib/dri/swrast_dri.so
#13 0x4abfa82c in opengl_renderer::set_polygon_offset (this=0x80610180,
     on=false, offset=0)
     at /usr/src/debug/octave-4.0.1-1/libinterp/corefcn/gl-render.cc:2916

However I see that also mesa-demos segfault

$ cd /usr/lib/mesa-demos
$ ./quad-clip.exe
GL_RENDERER   = Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits)
GL_VERSION    = 3.0 Mesa 11.0.9
GL_VENDOR     = VMware, Inc.
Segmentation fault (core dumped)

Regards
Marco


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

gdb using Windows paths in dlopen()ed modules?

[Yaakov Selkowitz]

On 2016-04-12 10:20, Marco Atzeri wrote:
> On 22/02/2016 10:00, Yaakov Selkowitz wrote:
>> The following packages have been uploaded to the Cygwin distribution:
>>
>> * mesa-11.0.9-2
>> * dri-drivers-11.0.9-2
>> * libglapi0-11.0.9-2
>> * libGL1-11.0.9-2
>> * libGL-devel-11.0.9-2
>> * libOSMesa8-11.0.9-2
>> * libOSMesa-devel-11.0.9-2
>> * libEGL1-11.0.9-2
>> * libEGL-devel-11.0.9-2
>> * libGLESv2_2-11.0.9-2
>> * libGLESv2-devel-11.0.9-2
>> * windowsdriproto-11.0.9-2
>>
>> Mesa is an open-source implementation of the OpenGL specification, a
>> system
>> for rendering interactive 3D graphics.
>>
>> Complete documentation on OpenGL usage and configuration can be found
>> here:
>>
>> http://x.cygwin.com/docs/ug/using-glx.html
>>
>> This release has been rebuilt for LLVM 3.7.
>>
>> --
>> Yaakov
>>
>
> Hi Yaakov,
> we found a case where the 32bit is segfaulting
> while dri-drivers-11.0.9-1
> works fine.
> For reference:
> https://cygwin.com/ml/cygwin/2016-04/msg00245.html
> https://cygwin.com/ml/cygwin/2016-04/msg00251.html
>
> To replicate with octave is enough :
> run from xterm
>    /usr/bin/octave-cli-4.0.1.exe
>
>   x=1:100;
>   plot(x,x)
>
> as dri-drivers seems absent from mesa-debuginfo
> I can not provide you a meaningful backtrace:
>
> #0  0xfc6d00a0 in ?? ()
> #1  0x43934357 in gallium_dri!__driDriverGetExtensions_swrast ()
>     from E:/cygwin/lib/dri/swrast_dri.so
[snip]
 > #14 0x4fc1ae48 in glutJoystickGetCenter () from /usr/bin/cygglut-3.dll

Corinna,

I'm seeing this as well.  Any idea why gdb is using with dlopen()ed 
modules?  This is preventing it from finding the split debuginfo.

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

Re: gdb using Windows paths in dlopen()ed modules?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

On Apr 12 21:16, Yaakov Selkowitz wrote:
> On 2016-04-12 10:20, Marco Atzeri wrote:
> >On 22/02/2016 10:00, Yaakov Selkowitz wrote:
> >>The following packages have been uploaded to the Cygwin distribution:
> >>
> >>* mesa-11.0.9-2
> >>* dri-drivers-11.0.9-2
> >>* libglapi0-11.0.9-2
> >>* libGL1-11.0.9-2
> >>* libGL-devel-11.0.9-2
> >>* libOSMesa8-11.0.9-2
> >>* libOSMesa-devel-11.0.9-2
> >>* libEGL1-11.0.9-2
> >>* libEGL-devel-11.0.9-2
> >>* libGLESv2_2-11.0.9-2
> >>* libGLESv2-devel-11.0.9-2
> >>* windowsdriproto-11.0.9-2
> >>
> >>Mesa is an open-source implementation of the OpenGL specification, a
> >>system
> >>for rendering interactive 3D graphics.
> >>
> >>Complete documentation on OpenGL usage and configuration can be found
> >>here:
> >>
> >>http://x.cygwin.com/docs/ug/using-glx.html
> >>
> >>This release has been rebuilt for LLVM 3.7.
> >>
> >>--
> >>Yaakov
> >>
> >
> >Hi Yaakov,
> >we found a case where the 32bit is segfaulting
> >while dri-drivers-11.0.9-1
> >works fine.
> >For reference:
> >https://cygwin.com/ml/cygwin/2016-04/msg00245.html
> >https://cygwin.com/ml/cygwin/2016-04/msg00251.html
> >
> >To replicate with octave is enough :
> >run from xterm
> >   /usr/bin/octave-cli-4.0.1.exe
> >
> >  x=1:100;
> >  plot(x,x)
> >
> >as dri-drivers seems absent from mesa-debuginfo
> >I can not provide you a meaningful backtrace:
> >
> >#0  0xfc6d00a0 in ?? ()
> >#1  0x43934357 in gallium_dri!__driDriverGetExtensions_swrast ()
> >    from E:/cygwin/lib/dri/swrast_dri.so
> [snip]
> > #14 0x4fc1ae48 in glutJoystickGetCenter () from /usr/bin/cygglut-3.dll
> 
> Corinna,
> 
> I'm seeing this as well.  Any idea why gdb is using with dlopen()ed modules?

Sorry, no.  Does that depend on the Cygwin version?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] mesa 11.0.9-2

[Yaakov Selkowitz]

On 2016-04-12 10:20, Marco Atzeri wrote:
> we found a case where the 32bit is segfaulting
> while dri-drivers-11.0.9-1
> works fine.
> For reference:
> https://cygwin.com/ml/cygwin/2016-04/msg00245.html
> https://cygwin.com/ml/cygwin/2016-04/msg00251.html
>
> To replicate with octave is enough :
> run from xterm
>    /usr/bin/octave-cli-4.0.1.exe
>
>   x=1:100;
>   plot(x,x)
>
> However I see that also mesa-demos segfault
>
> $ cd /usr/lib/mesa-demos
> $ ./quad-clip.exe
> GL_RENDERER   = Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits)
> GL_VERSION    = 3.0 Mesa 11.0.9
> GL_VENDOR     = VMware, Inc.
> Segmentation fault (core dumped)

I can reproduce this on 32-bit but not 64-bit, and the same happens with 
11.1.2.  It may be an issue with LLVM 3.7 (11.0.9-1 was built with 3.5) 
but without a useful backtrace it will be hard to pin down.

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

Re: [ANNOUNCEMENT] mesa 11.0.9-2

[Marco Atzeri]

On 13/04/2016 04:33, Yaakov Selkowitz wrote:
> On 2016-04-12 10:20, Marco Atzeri wrote:
>> we found a case where the 32bit is segfaulting
>> while dri-drivers-11.0.9-1
>> works fine.
>> For reference:
>> https://cygwin.com/ml/cygwin/2016-04/msg00245.html
>> https://cygwin.com/ml/cygwin/2016-04/msg00251.html
>>
>> To replicate with octave is enough :
>> run from xterm
>>    /usr/bin/octave-cli-4.0.1.exe
>>
>>   x=1:100;
>>   plot(x,x)
>>
>> However I see that also mesa-demos segfault
>>
>> $ cd /usr/lib/mesa-demos
>> $ ./quad-clip.exe
>> GL_RENDERER   = Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits)
>> GL_VERSION    = 3.0 Mesa 11.0.9
>> GL_VENDOR     = VMware, Inc.
>> Segmentation fault (core dumped)
>
> I can reproduce this on 32-bit but not 64-bit, and the same happens with
> 11.1.2.  It may be an issue with LLVM 3.7 (11.0.9-1 was built with 3.5)
> but without a useful backtrace it will be hard to pin down.
>

Hi Yaakov,

until the root cause is not pinned down,
can you re-put 11.0.9-1 as current for 32bit and
leave all the new version as tests ?

With current 11.2.2-1 and previous 11.2.1-1 both not working
we have an issue.

Regards
Marco


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

Re: [ANNOUNCEMENT] mesa 11.0.9-2

[Jon Turney]

On 31/05/2016 18:03, Jon Turney wrote:
> On 13/04/2016 03:33, Yaakov Selkowitz wrote:
>> On 2016-04-12 10:20, Marco Atzeri wrote:
>>> $ cd /usr/lib/mesa-demos
>>> $ ./quad-clip.exe
>>> GL_RENDERER   = Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits)
>>> GL_VERSION    = 3.0 Mesa 11.0.9
>>> GL_VENDOR     = VMware, Inc.
>>> Segmentation fault (core dumped)
>>
>> I can reproduce this on 32-bit but not 64-bit, and the same happens with
>> 11.1.2.  It may be an issue with LLVM 3.7 (11.0.9-1 was built with 3.5)
>> but without a useful backtrace it will be hard to pin down.
>
> gdb can successfully backtrace this, with today's cygwin snapshot.
>
> Both examples of the crash provided by Marco show very similar symptoms.
>
> Unfortunately, the backtrace stops at llvm_pipeline_generic() calling
> into some JIT-ed code.  The faulting is at an insertps instruction with
> what looks like a bogus absolute address.
>
> So I guess this some is an llvm issue, possibly with some address
> computation which doesn't give the right result on 32 bit?
>
>> # 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...


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

Re: [ANNOUNCEMENT] mesa 11.0.9-2

[Yaakov Selkowitz]

On 2016-06-03 12:56, Jon Turney wrote:
> On 31/05/2016 18:03, Jon Turney wrote:
>> On 13/04/2016 03:33, Yaakov Selkowitz wrote:
>>> On 2016-04-12 10:20, Marco Atzeri wrote:
>>>> $ cd /usr/lib/mesa-demos
>>>> $ ./quad-clip.exe
>>>> GL_RENDERER   = Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits)
>>>> GL_VERSION    = 3.0 Mesa 11.0.9
>>>> GL_VENDOR     = VMware, Inc.
>>>> Segmentation fault (core dumped)
>>>
>>> I can reproduce this on 32-bit but not 64-bit, and the same happens with
>>> 11.1.2.  It may be an issue with LLVM 3.7 (11.0.9-1 was built with 3.5)
>>> but without a useful backtrace it will be hard to pin down.
>>
>> gdb can successfully backtrace this, with today's cygwin snapshot.
>>
>> Both examples of the crash provided by Marco show very similar symptoms.
>>
>> Unfortunately, the backtrace stops at llvm_pipeline_generic() calling
>> into some JIT-ed code.  The faulting is at an insertps instruction with
>> what looks like a bogus absolute address.
>>
>> So I guess this some is an llvm issue, possibly with some address
>> computation which doesn't give the right result on 32 bit?
>>
>>> # 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.

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

Re: [ANNOUNCEMENT] mesa 11.0.9-2

[Jon Turney]

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

[1] http://llvm.org/viewvc/llvm-project?view=revision&revision=251761


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

Re: [ANNOUNCEMENT] mesa 11.0.9-2 [GOLDSTAR]

[Yaakov Selkowitz]

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

Re: [ANNOUNCEMENT] mesa 11.0.9-2 [GOLDSTAR]

[Marco Atzeri]

On 10/06/2016 00:01, Yaakov Selkowitz wrote:
>
> 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?

Only one ?

Regards
Marco



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

Re: [ANNOUNCEMENT] mesa 11.0.9-2 [GOLDSTAR]

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Jun 10 06:18, Marco Atzeri wrote:
> On 10/06/2016 00:01, Yaakov Selkowitz wrote:
> > 
> > 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?
> 
> Only one ?

Jon already got a goldstar *and* a plush hippo this year.  Do we look
like the Bank of England?  This stuff is expensive!!1!!11


Have fun,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] mesa 11.0.9-2 [GOLDSTAR]

[Andrew Schulman]

> 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?

Awarded!  http://cygwin.com/goldstars/#JTy


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

Re: [ANNOUNCEMENT] mesa 11.0.9-2 [GOLDSTAR]

[Jon Turney]

On 09/06/2016 23:01, Yaakov Selkowitz wrote:
> On 6/6/2016 9:27 AM, Jon Turney wrote:
>>
>> 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.

There's a few more details in the llvm bug I raised [1].

This is now fixed in llvm master, but will need patching in llvm 3.8, if 
that is packaged.

[1] https://llvm.org/bugs/show_bug.cgi?id=28111

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