[RFC] powerpc: restore TOC when static longjmp to shared object
Rogerio Alves
rcardoso@linux.vnet.ibm.com
Mon Jun 4 14:34:00 GMT 2018
This is v3 of patch. As pointed out by Alexander Monakov we can't rely
on alloca/memset since gcc can optimize this out or it can save the
registers on the stack and the test will no longer make sense.
Now I use small asm code to deliberately overwrite TOC area on caller
frame with zero. If the TOC is not restored by longjmp the test will
fail and them I removed alloca/memset since it's no longer necessary for
the test itself.
Em 25-05-2018 16:39, Rogerio Alves escreveu:
>
>
> Em 23-05-2018 11:24, Alexander Monakov escreveu:
>> On Wed, 23 May 2018, Rogerio Alves wrote:
>>> I don't think that alloca/memset should destroy the caller stack like is
>>> happening but, also I think we have to restore TOC to the caller
>>> frame after
>>> the longjmp in that case also. I don't know if there's any other more
>>> direct
>>> and robust ways to checking if TOC is correctly restored. I can't
>>> think in
>>> anything easier than always restore.
>>
>> I'm not challenging the idea that "always restoring" is an appropriate
>> fix.
>> My question was about *verifying* that TOC register is restored as it
>> ought
>> to, i.e. how the testcase needs to work. Right now, the test uses my code
>> from Bugzilla that worked okay for demonstration purposes, but has
>> issues as
>> a long-term testsuite addition:
>>
>> * it demonstrates the issue in a very intransparent fashion, relying on
>> Â Â non-obvious interaction with alloca-memset part of the test;
>>
>> * when GCC manages to optimize out the alloca-memset part, the test
>> Â Â will cease to work for the intended purpose.
>>
>> Alexander
>>
>
> Ok. I understand your concern. Let me see if I can change this test to
> check if the TOC was been restored.
>
> Rogerio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-powerpc-Always-restore-TOC-on-longjmp.patch
Type: text/x-patch
Size: 7055 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20180604/2bd378c8/attachment.bin>
More information about the Libc-alpha
mailing list