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

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

[Maciej W. Rozycki]

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.

 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

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

[Matthew Fortune]

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

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

[Matthew Fortune]

Matthew Fortune <matthew.fortune@imgtec.com> writes:
> 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.

Any further opinions on this (whether to make it arch-independent or
just a new MIPS tag)?

Matthew

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

[Roland McGrath]

I think it makes sense to define this arch-independent.

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

[Matthew Fortune]

Roland McGrath <roland@hack.frob.com> writes:
> I think it makes sense to define this arch-independent.

OK, unless anyone objects I will prepare patches on that basis.

It looks like there are no GNU tags defined yet in the 'new'
OS range for tags. Should I just take the first one?

#define DT_GNU_RLD_MAP 0x6000000d

thanks,
Matthew

== from binutils include/elf/common.h ==

/* Note, the Oct 4, 1999 draft of the ELF ABI changed the values
   for DT_LOOS and DT_HIOS.  Some implementations however, use
   values outside of the new range (see below).  */
#define OLD_DT_LOOS     0x60000000
#define DT_LOOS         0x6000000d
#define DT_HIOS         0x6ffff000
#define OLD_DT_HIOS     0x6fffffff

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

[Maciej W. Rozycki]

On Thu, 13 Nov 2014, Matthew Fortune wrote:

> OK, unless anyone objects I will prepare patches on that basis.
> 
> It looks like there are no GNU tags defined yet in the 'new'
> OS range for tags. Should I just take the first one?
> 
> #define DT_GNU_RLD_MAP 0x6000000d

 That would be the natural choice in my opinion unless someone already 
uses it for something in a private tree or branch and did not mention it 
so far, but plans to submit their code.  I think we shouldn't be causing 
hassle to anyone unnecessarily.  Do we have a place (other than the 
relevant pieces of source code) we use to document our (GNU) ABI 
conventions?

  Maciej

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

[Roland McGrath]

> Do we have a place (other than the relevant pieces of source code) we use
> to document our (GNU) ABI conventions?

I think the de facto "source of truth" for this has heretofore been the
binutils trunk include/ sources.

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

[Matthew Fortune]

> On Thu, 13 Nov 2014, Matthew Fortune wrote:
> 
> > OK, unless anyone objects I will prepare patches on that basis.
> >
> > It looks like there are no GNU tags defined yet in the 'new'
> > OS range for tags. Should I just take the first one?
> >
> > #define DT_GNU_RLD_MAP 0x6000000d
> 
>  That would be the natural choice in my opinion unless someone already
> uses it for something in a private tree or branch and did not mention it
> so far, but plans to submit their code.  I think we shouldn't be causing
> hassle to anyone unnecessarily.  Do we have a place (other than the
> relevant pieces of source code) we use to document our (GNU) ABI
> conventions?

One concern is over what the GNU ABI encompasses. I.e. We have glibc, uclibc
musl and bionic (that I know of) which provide dynamic linker functionality
with the linux kernel. If they are independently allowed to define tags then
there is a high chance of collision and bugs from accidentally getting a linker
to target the wrong 'OS'.

So do we have to take the 'GNU' OS to mean anything which provides dynamic
linking on linux? Is there already a description of what it means and/or can
someone think of a sensible description?

In some ways doing this as an architecture independent extension may actually
require specifying it in the ELF ABI itself.

Thanks,
Matthew