This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Maciej W. Rozycki <macro@codesourcery.com> writes:
> 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.

That sounds like a reasonable plan too. I wasn't expecting to go with the
let it crash plan but all options need to be presented.

I'm not sure about using the old name with a new tag as it is listed in the
original psABI I believe. For safety a PIE could only get the new tag rather
than both of course but a standard executable could have both I guess.

I'm a bit stumped as to what the technical benefit was/is about having a read
only dynamic section. Does anyone know?

I think overall Maciej's suggestion of a new tag sounds like the most
pleasant option so far as it doesn't need .dynamic to be writable and is
therefore more similar to non-PIE.

Matthew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]