This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Potential issue with strstr on x86 with sse4.2 in glibc-2.18


On Tue, Aug 20, 2013 at 08:55:52AM +1000, Allan McRae wrote:
> On 20/08/13 01:54, Alexander Monakov wrote:
> > On Mon, 19 Aug 2013, Rich Felker wrote:
> >> Really this doesn't even look like a case of a legacy binary, but
> >> rather fglrx's libGL.so.1 simply containing incorrect asm (or just
> >> CFLAGS?) that doesn't match the modern psABI calling convention. It
> >> would probably be best to pressure its maintainers to fix this bug on
> >> their side...
> > 
> > I'm afraid what's more likely to happen in practice is distributions being
> > pressured by users to pick up the patch reinstating the inline keywords in
> > strstr.c.  Allan, what are you going to do in Arch Linux about this?  Keep
> > patching upstream, or drop the patch, let FGLRX break and tell users to
> > complain to AMD, or... ?  [I do realize that the two former options are bad]
> 
> Currently I have reinstated the inline keyword for Arch Linux.  We have
> no issues declaring no support for FGRLX, because we do not support it
> anyway!  AMD are too slow at updating with Xorg releases so we dropped
> it from our repos.
> 
> But the most important thing, the person who bisected this fix was not
> using fgrlx for their libGL.so.1.   They were using Mesa.   And I see
> reports of Skype and Steam failing with both Intel and NVIDIA drivers.
> So binary blobs failing for all graphics drivers, and widespread
> failures for FGRLX.
> 
> So does that just leave us the option of realigning the stack for the
> relevant calls?

Does -mincoming-stack-boundary=2 -mpreferred-stack-boundary=4 cause
realignment to take place in the prologue of every function, or only
functions that use SSE? If the latter, I think a safe solution would
be to use these options globally, and possibly the related
-mstackrealign or force_align_arg_pointer attribute on functions which
call back to application code. This would fix the problem not just for
the "relevant" calls, but for any functions in which GCC happens to
emit SSE code. Of course the size and performance costs would need to
be measured...

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]