Re: [PATCH 14/17 v5] Avoid stack-protecting signal-handling functions sibcalled from assembly.

[Nix <nix at esperi dot org dot uk>]

On 13 May 2016, Florian Weimer told this:

> On 03/13/2016 04:16 PM, Nix wrote:
>> Certain signal-handling functions are sibcalled from assembly on
>> x86, both on Linux and the Hurd.  As such, they depend on having
>> the same-shaped stack frame, an assumption it seems likely that
>> -fstack-protector violates.
>
> I think that's not actually true for tail calls to stack-protector-enabled functions from those who are not so enabled.
>
> The lack of rebuild is more problematic.  Does it really make a difference, considering that the affected function is not active
> while we initialize the stack guard value?

I was being paranoid and aiming for stability given that at the time I
didn't know what caused the locking-related crashes on x86-32 when
stack-protection was enabled, and thought this was a plausible victim as
well.

In hindsight, given that we now know it was a missing reload of a
call-clobbered register in that specific case and not something to do
with some sort of stack-frame incompatibility between stack-protected
and non-stack-protected code, it seems likely that we can drop this (and
the corresponding sparc changes).

I'll roll a new patch series with that done and with the changes
requested a few weeks ago by Mike, and sans the stuff that's already
been pulled in, this weekend, and see if they pass their checks. (The
posting of the patches might not follow until early next week, because
all those make checks take a long time, particularly on my little ARM
home cinema box. :) )

-- 
NULL && (void)