[RFC] powerpc: restore TOC when static longjmp to shared object

Rogerio Alves rcardoso@linux.vnet.ibm.com
Wed May 16 19:36:00 GMT 2018


Attached to this email I am sending the first version of the patch but I 
have a problem with this patch. I can't make the test work. By some 
reason it can't find the .so needed by the test:

FAIL:
./setjmp-bug21895.so: cannot open shared object file: No such file or 
directory

Notice that if I manually execute the command on make check stdout 
inside the folder it works fine. I'd appreciate any help on that.

Regards

Em 15-05-2018 17:48, Tulio Magno Quites Machado Filho escreveu:
> 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.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PATCH-v1-powerpc-Always-restore-TOC-on-longjmp.patch
Type: text/x-patch
Size: 6296 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20180516/b46c3b04/attachment.bin>


More information about the Libc-alpha mailing list