There are times where it is necessary to patch ELF files so that they have correct paths to things. Most of the things that they want to be able to update are in the .dynstr section e.g. RPATH and RUNPATH. It would be helpful if the strings in .dynstr were padded with some additional space so that they could be lengthened not just shortened or remain the same length. Evidently Solaris used to do this and it was helpful. Can we either make ld pad these strings when it makes a binary by default or have an option to pad out these strings when linking so that we have some more room in the .dynstr section should we need to update paths. I do not know the best amount of padding. I bet that an extra 256 or 512 bytes per entry would be sufficient for all but the most unusual use cases.
This is a rare operation. I don't think a built-in feature is necessary. You can additionally link an object file with an artificial long symbol name. Since that symbol is not used, you can change its .dynstr
(In reply to Fangrui Song from comment #1) > You can additionally link an object file with an artificial long symbol > name. Since that symbol is not used, you can change its .dynstr I think that is really fragile. The way Solaris does this (what I assume Ben, the original reporter, is after) is by introducing a new dynamic section entry that provides the padding that is still available. That way tools know where and how much space they can use for dynamic strings. We could introduce DT_GNU_STRPAD and suggest that linkers initially set it to 256 (and add that to DT_STRSZ) to make such manipulations easy and robust. Any tool manipulating the .dynstr segement can then use (and update) that when adding a new string. See also: http://www.linker-aliens.org/blogs/ali/entry/changing_elf_runpaths/
Do you think it is worth me chiming in saying ‘what he said’? You captured my intent perfectly. I guess I’m kind of hung up on “assume” in “what I assume Ben, the original reporter, is after” or is that just a polite assume. -ben > On Mar 7, 2021, at 9:04 AM, mark at klomp dot org <sourceware-bugzilla@sourceware.org> wrote: > > https://sourceware.org/bugzilla/show_bug.cgi?id=26706 > > --- Comment #2 from Mark Wielaard <mark at klomp dot org> --- > (In reply to Fangrui Song from comment #1) >> You can additionally link an object file with an artificial long symbol >> name. Since that symbol is not used, you can change its .dynstr > > I think that is really fragile. The way Solaris does this (what I assume Ben, > the original reporter, is after) is by introducing a new dynamic section entry > that provides the padding that is still available. That way tools know where > and how much space they can use for dynamic strings. > > We could introduce DT_GNU_STRPAD and suggest that linkers initially set it to > 256 (and add that to DT_STRSZ) to make such manipulations easy and robust. Any > tool manipulating the .dynstr segement can then use (and update) that when > adding a new string. > > See also: http://www.linker-aliens.org/blogs/ali/entry/changing_elf_runpaths/ > > -- > You are receiving this mail because: > You reported the bug.
Hi Ben, Bugzilla tricked you and changed the from so your reply went directly into the bug. On Tue, Mar 09, 2021 at 12:41:46AM +0000, woodard at redhat dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=26706 > > --- Comment #3 from Ben Woodard <woodard at redhat dot com> --- > Do you think it is worth me chiming in saying ‘what he said’? You captured my > intent perfectly. I guess I’m kind of hung up on “assume” in “what I assume > Ben, the original reporter, is after” or is that just a polite assume. So you just did chime in with an "what he said". Thanks! Of course it was a polite assume, I always try to be polite :) Just didn't want to put any words in your mouth, even though I was pretty sure because we had discussed the way Solaris solved it before. Just wanted to provide some background pointers. But yes, it probably should have read "what I know", but that sounded so presumptious. Cheers, Mark