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: [RFC] powerpc: restore TOC when static longjmp to shared object




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


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