Re: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Wed, 22 Oct 2014, Matthew Fortune wrote:

> Currently binutils will not emit a DT_MIPS_RLD_MAP entry for PIE
> as the condition for emitting this is '!shared' rather than
> 'executable'. If binutils were to start emitting DT_MIPS_RLD_MAP
> for PIE then ld.so (and GDB) would need to calculate the real
> address of the debug pointer by adding the base of the executable
> to the offset in the DT_MIPS_RLD_MAP entry. This is possible
> but will result in new PIE binaries crashing ld.so as the value
> of DT_MIPS_RLD_MAP is dereferenced directly.
> 
> Realistically I don't think there is any way to avoid this crash
> if we start emiting DT_MIPS_RLD_MAP for PIE. So we either have
> to take that as a known issue (and do the work in ld.so
> and gdb/gdbserver to account for PIE) OR we choose to define
> the ABI for MIPS PIE to use DT_DEBUG instead of DT_MIPS_RLD_MAP
> and allow the dynamic section to be writable for PIE (and only
> PIE). The dynamic linker logic would be to fill out
> DT_MIPS_RLD_MAP if it is present and iff not then fill out
> DT_DEBUG if it is present. GDB probably wouldn't need any
> changes but I didn't check in detail.
> 
> There's work to do either way but which one is 'better'?

 Or we could define an entirely new dynamic tag that'll be ignored by old 
software.  It's not like we're short of them.  It can point to the same 
area DT_MIPS_RLD_MAP would; in fact we can even produce both at a time for 
maximum backwards compatibility, and maybe go as far as to rename the old 
macro and use the old name with the new tag.  Deliberately letting newer 
binaries crash with older software sounds like an awful design decision to 
me.

  Maciej