This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] powerpc: restore TOC when static longjmp to shared object
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Rogerio Alves <rcardoso at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 15 May 2018 20:50:56 +0200
- Subject: Re: [RFC] powerpc: restore TOC when static longjmp to shared object
- References: <5e8159c9-f6d2-9429-479b-fe436a7f2a88@linux.vnet.ibm.com>
* Rogerio Alves:
> One simple solution would be always restore the TOC pointer by uncomment
> the line bellow:
>
> /* std r2,FRAME_TOC_SAVE(r1) Restore the TOC save area. */
>
> Or maybe we can check if we have a valid TOC pointer before restore it,
> instead #if defined SHARED.
Is the register reserved for the TOC pointer in static builds, too?
Then I suggest to unconditionally save nad restore it; not doing so
looks like a pointless micro-optimization.
Another problem with sharing jump buffers across static dlopen is that
you might not have identical pointer guard values.
> I would like to request for comments on this matter: Should we fix/work
> this? Is feasible to change longjmp to always restore TOC pointer?
Does setjmp already save it unonditionally?
Removal of static dlopen is still some time away; it's likely not
going to happen in this cycle, and the fix looks simple enough.