Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Roland McGrath <roland@hack.frob.com>
Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>,
	Richard Sandiford	<rdsandiford@googlemail.com>,
	<binutils@sourceware.org>,	<libc-alpha@sourceware.org>,
	<gdb@sourceware.org>,
	"Joseph Myers (joseph@codesourcery.com)"
	<joseph@codesourcery.com>,
	"Moore,
	Catherine (Catherine_Moore@mentor.com)"
	<Catherine_Moore@mentor.com>,
	Nikola Veljkovic	<Nikola.Veljkovic@imgtec.com>
Subject: RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE
Date: Thu, 30 Oct 2014 23:53:00 -0000	[thread overview]
Message-ID: <alpine.DEB.1.10.1410302305320.7896@tp.orcam.me.uk> (raw)
In-Reply-To: <20141030193816.E80F82C3B18@topped-with-meat.com>

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


       reply	other threads:[~2014-10-30 23:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6D39441BF12EF246A7ABCE6654B0235320F3027E@LEMAIL01.le.imgtec.org>
     [not found] ` <alpine.DEB.1.10.1410221755430.7896@tp.orcam.me.uk>
     [not found]   ` <6D39441BF12EF246A7ABCE6654B0235320F30462@LEMAIL01.le.imgtec.org>
     [not found]     ` <871tpy37ir.fsf@googlemail.com>
     [not found]       ` <6D39441BF12EF246A7ABCE6654B0235320F385FA@LEMAIL01.le.imgtec.org>
     [not found]         ` <alpine.DEB.1.10.1410301835480.7896@tp.orcam.me.uk>
     [not found]           ` <20141030193816.E80F82C3B18@topped-with-meat.com>
2014-10-30 23:53             ` Maciej W. Rozycki [this message]
2014-11-04 11:14               ` Matthew Fortune
2014-11-12 23:11                 ` Matthew Fortune
2014-11-12 23:32                   ` Roland McGrath
2014-11-13 16:37                     ` Matthew Fortune
2014-11-13 18:00                       ` Maciej W. Rozycki
2014-11-13 19:10                         ` Roland McGrath
2014-11-14 11:27                         ` Matthew Fortune

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.1.10.1410302305320.7896@tp.orcam.me.uk \
    --to=macro@codesourcery.com \
    --cc=Catherine_Moore@mentor.com \
    --cc=Matthew.Fortune@imgtec.com \
    --cc=Nikola.Veljkovic@imgtec.com \
    --cc=binutils@sourceware.org \
    --cc=gdb@sourceware.org \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=rdsandiford@googlemail.com \
    --cc=roland@hack.frob.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox