patch for broken thunk on sparc

[Alexey Starovoytov]

On Sat, 8 Apr 2006, Eric Botcazou wrote:

>> Could you illustrate your assertion of 'clobber the previous frame' in
>> the current patch?
>
> We decrement the stack pointer by 2 words in the thunk then write something at
> sp+92/96 (without the SPARC_STACK_ALIGN stuff).  I presume you consider that
> as a mere dynamic allocation in the previous frame, right?  I'd agree, except
> that the caller of the thunk doesn't know that the thunk is going to allocate
> stack space behind its back and write in its frame.  The compiler enforces
> some restrictions for functions that do dynamic stack allocation.
>
> Are you convinced it's OK to do that?  If so, I'm ready to trust you but I'd
> request a comment in the code explaining it.

Using dynamic stack allocation without creating a frame was a very hacky idea
from the very beginning.
I tried to patch it a bit without rewriting the whole thing and the patch will
work just because such thunk calls only "pic-helper" function and restore
%sp back immediately.

The caller of the thunk will not see the change of the %sp unless there is
a signal handler that somehow gets triggered in the middle of the thunk.

> Another nit: why do you align the offset in 32-bit mode?  We only need word
> alignment here.

Just for the sake of consistency with normal dynamic stack alloc.
Actually any offset between +64 and +100 will work for this particular thunk,
but +68 has a small chance of being clobbered by the signal handler executed 
in the middle of the thunk.

Alex.