RE: [RFD] How legal is it to delete dynamic tags?

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Nathaniel Smith <njs@pobox.com> writes:
> On Fri, Apr 15, 2016 at 4:13 PM, Nathaniel Smith <njs@pobox.com> wrote:
> > On Fri, Apr 15, 2016 at 8:08 AM, Matthew Fortune
> > <Matthew.Fortune@imgtec.com> wrote:
> >> I have a bug report from Debian showing that the DT_MIPS_RLD_MAP_REL
> >> tag (introduced on MIPS to support shared library debug with PIE)
> >> can be corrupted by a program called chrpath.
> >>
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818909#43
> >>
> >> chrpath is designed to alter or remove DT_RPATH entries. Removal is
> >> a problem when such an entry precedes DT_MIPS_RLD_MAP_REL as the
> >> relative offset stored in DT_MIPS_RLD_MAP_REL then points to the
> >> wrong address.
> >>
> >> Firstly, to what extent is it OK to just delete a dynamic tag rather
> >> than set it to DT_NULL?
> >>
> >> Secondly was it a bad decision to create a slot-relative dynamic
> >> tag? I.e. If I were to fix chrpath to know that DT_MIPS_RLD_MAP_REL
> >> needs updating... are there likely to be more utilities out there
> >> that fiddle with dynamic tags in this way?
> >
> > There's patchelf at least, which is like a fancier version of chrpath:
> >
> >   https://github.com/NixOS/patchelf
> >
> > So it probably has the same bug when deleting DT_RPATH / DT_RUNPATH /
> > DT_NEED entries. Also, some of patchelf's operations add new entries
> > to the dynamic tag table (e.g. adding a new DT_RUNPATH or DT_NEED
> > entry), which I think ends up involving larger rearrangements of the
> > file (e.g. moving the whole table to somewhere else where there's room
> > to expand it); it's likely that this might cause problems for your
> > slot-relative tag as well.
> 
> Actually, it looks like in some cases (but not all), patchelf deletes
> entries from the dynamic tag table by leaving them their but setting
> their type to a magic "DT_IGNORE" value:
> 
> https://github.com/NixOS/patchelf/blob/77efcf2f2d2f95391a6717cc9457f87267500e72/src/patche
> lf.cc#L222-223
> 
> No idea if this DT_IGNORE thing has any precedent in the ELF spec
> (google doesn't seem to find any references to it outside of the
> patchelf source), but apparently it works in practice. You still have
> the problems that patchelf doesn't use it consistently, chrpath
> doesn't use it at all, and that there are other cases where patchelf
> needs to move DT entries, but I guess using this DT_IGNORE thing would
> work to solve the narrow chrpath problem that started the thread :-).

Thanks Nathaniel,

I didn't know about patchelf either so I'll see if I can get it updated
similarly to chrpath.

Matthew