Reserving specified size of RUNPATH entry in the dynamic section during linking
Jacob Kroon
jacob.kroon@gmail.com
Sun Nov 28 15:54:05 GMT 2021
On 11/28/21 16:17, Florian Weimer wrote:
> * Jacob Kroon:
>
>>> The RUNPATH strings are in the string table, so it's necessary to
>>> allocate space there, and be able to find it during patching.
>>>
>>> Solaris offers this mechanism:
>>>
>>> | DT_SUNW_STRPAD
>>> |
>>> | The total size, in bytes, of the unused reserved space at the end of
>>> | the dynamic string table. If DT_SUNW_STRPAD is not present in an
>>> | object, no reserved space is available.
>>>
>>> Would that help in your case as well?
>>>
>>
>> The problem is that for two different build I pass two different
>> -Wl,--rpath=<path>, and they are of different length. So I'd like to
>> reserve a maximum size, at link-time, which becomes the same in both
>> builds, so that when I later remove the rpath's, the binaries become
>> identical.
>
> In the file, there is no array of some number of characters that
> contains the null-terminated RUNPATH string, an array to which just more
> null bytes could be added at the end. DT_RUNPATH contains an offset
> into the string table. The null-terminated string could be used for
> something else. For example, if the RUNPATH is
> "/usr/lib64/sys/library.so.3", and the link edit needs the string
> "library.so.3" for something else, it can point into the RUNPATH string
> to get that. So it's not valid in general to patch the string in-place,
> let alone change its length.
>
> That's why I think something like the Solaris approach is needed: The
> new RUNPATH value would come from the reservation, the offset in
> DT_RUNPATH points to it, and the original string table is not modified
> at all.
>
Aha, thank you for explaining.
I suppose gnu ld doesn't try to optimize for usage of substrings in
RUNPATH, thus making if fairly easy to change it post linking.
But can I then specify during link time that RUNTIME should go in a
"reserved" area, whose size I can also control ? I hope I understood you
correctly.
Jacob
More information about the Gcc-help
mailing list