This is the mail archive of the
mailing list for the binutils project.
RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "Maciej W. Rozycki" <macro at codesourcery dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "Joseph Myers (joseph at codesourcery dot com)" <joseph at codesourcery dot com>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>, Nikola Veljkovic <Nikola dot Veljkovic at imgtec dot com>
- Date: Thu, 30 Oct 2014 17:44:41 +0000
- Subject: RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320F3027E at LEMAIL01 dot le dot imgtec dot org> <alpine dot DEB dot 1 dot 10 dot 1410221755430 dot 7896 at tp dot orcam dot me dot uk> <6D39441BF12EF246A7ABCE6654B0235320F30462 at LEMAIL01 dot le dot imgtec dot org> <871tpy37ir dot fsf at googlemail dot com>
Richard Sandiford <firstname.lastname@example.org> writes:
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > Maciej W. Rozycki <email@example.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
> >> 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
> >> 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
> > original psABI I believe. For safety a PIE could only get the new tag
> > 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
> > 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.
> Sounds good to me too FWIW.
OK, let's go with that. Time to decide on a name. How about
DT_MIPS_RLD_MAP_PIE? Long but potentially accurate. We are going to have to
drag around DT_MIPS_RLD_MAP forever I believe so I suggest we focus the
new name on the scenario where it is required.