This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Potential issue with strstr on x86 with sse4.2 in glibc-2.18
- From: Allan McRae <allan at archlinux dot org>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, libc-alpha at sourceware dot org
- Date: Tue, 20 Aug 2013 13:28:56 +1000
- Subject: Re: Potential issue with strstr on x86 with sse4.2 in glibc-2.18
- References: <520E181D dot 2040308 at archlinux dot org> <alpine dot LNX dot 2 dot 00 dot 1308191628370 dot 2626 at monopod dot intra dot ispras dot ru> <20130819144648 dot GF20515 at brightrain dot aerifal dot cx> <alpine dot LNX dot 2 dot 00 dot 1308191924490 dot 2626 at monopod dot intra dot ispras dot ru> <5212A278 dot 3090909 at archlinux dot org> <20130819230644 dot GM20515 at brightrain dot aerifal dot cx>
On 20/08/13 09:06, Rich Felker wrote:
> 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...
I would have assumed that it is gcc's responsibility to ensure alignment
if it decides to use SSE and our responsibility if our functions
explicitly use SSE. Is that being too naive?
Allan