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: "Maciej W. Rozycki" <macro at codesourcery dot com>, Roland McGrath <roland at hack dot frob dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "gdb at sourceware dot org" <gdb 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: Tue, 4 Nov 2014 11:14:07 +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> <6D39441BF12EF246A7ABCE6654B0235320F385FA at LEMAIL01 dot le dot imgtec dot org> <alpine dot DEB dot 1 dot 10 dot 1410301835480 dot 7896 at tp dot orcam dot me dot uk> <20141030193816 dot E80F82C3B18 at topped-with-meat dot com> <alpine dot DEB dot 1 dot 10 dot 1410302305320 dot 7896 at tp dot orcam dot me dot uk>
Maciej W. Rozycki <firstname.lastname@example.org> writes:
> On Thu, 30 Oct 2014, Roland McGrath wrote:
> > > Alternatively, we could cook up a generic DT_GNU_RLD_MAP tag for
> > > platforms that want to opt in to a read-only dynamic section/segment
> > > start using it with the MIPS target first. I think I like the latter
> > > bit better, any thoughts, anyone?
> > What's the specification of this tag's semantics?
> Here's what the 32-bit MIPS psABI says about it:
> This member is used by debugging. It contains the
> address of a 32-bit word in the .data section which is
> supplied by the compilation environment. The word's
> contents are not specified and programs using this value
> are not ABI - compliant."
> In a 64-bit ELF file the word is 64-bit instead; the 64-bit MIPS ELF
> specification mentions the tag, but does not document it further.
> The GNU toolchain does not really use a location in the `.data' section;
> instead the BFD linker creates a separate `.rld_map' section that spans
> only this piece of data, and points DT_MIPS_RLD_MAP at it. The section is
> then mapped to a writable segment.
> Our `ld.so' then puts the address of its link map there just as it puts
> it directly into the DT_DEBUG tag if present instead. The value of the
> DT_MIPS_RLD_MAP tag is intepreted as a final virtual memory address and
> therefore does not work for PIE executables though.
> For a new DT_GNU_RLD_MAP to work universally, both for traditional and
> PIE executables, I propose that the contents of this tag were not an
> address of, but a relative offset from the location of the tag to the
> location referred. This will be straightforward to handle in GDB too.
I hadn't thought of just using the address of the DT_*RLD_MAP entry. It
does look like it would be easy to implement.
If we choose to define a DT_GNU_RLD_MAP then I guess it should fit in with
the tags which use the d_val rather than d_ptr as it is an offset rather
than address. Proposed value is below:
#define DT_GNU_RLD_MAP 0x6ffffdf4
I unfortunately have to provide some solution to this out-of-tree to keep
android development moving so will temporarily use a processor specific
tag and switch to whatever this thread concludes. I'll use the scheme
described here though for the content of the tag.
>  "SYSTEM V APPLICATION BINARY INTERFACE, MIPS RISC Processor
> Supplement, 3rd Edition"
>  "64-bit ELF Object File Specification, Draft Version 2.5"