Re: Reserving specified size of RUNPATH entry in the dynamic section during linking

[Jacob Kroon <jacob.kroon@gmail.com>]

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