[RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE
Tue Nov 4 11:14:00 GMT 2014
Maciej W. Rozycki <email@example.com> 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"
More information about the Binutils