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: Tulio Magno Quites Machado Filho <tuliom at linux dot ibm dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>, Rogerio Alves <rcardoso at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Cc:
- Date: Tue, 15 May 2018 17:48:55 -0300
- Subject: Re: [RFC] powerpc: restore TOC when static longjmp to shared object
- References: <5e8159c9-f6d2-9429-479b-fe436a7f2a88@linux.vnet.ibm.com> <87tvr8u50v.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> writes:
> * 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.
If static dlopen is still going to be supported for some cycles, I also agree
it should be saved and restored unconditionally.
--
Tulio Magno