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

Maciej W. Rozycki <[email protected]> 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
> and
> > > start using it with the MIPS target first.  I think I like the latter
> a
> > > bit better, any thoughts, anyone?
> >
> > What's the specification of this tag's semantics?
> 
>  Here's what the 32-bit MIPS psABI[1] says about it:
> 
> "DT_MIPS_RLD_MAP
>                 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[2] 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.

Thanks,
Matthew

> 
>  References:
> 
> [1] "SYSTEM V APPLICATION BINARY INTERFACE, MIPS RISC Processor
>     Supplement, 3rd Edition"
>     http://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
> 
> [2] "64-bit ELF Object File Specification, Draft Version 2.5"
>     http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-
> 4658-001.pdf
> 
>   Maciej