* RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE [not found] ` <20141030193816.E80F82C3B18@topped-with-meat.com> @ 2014-10-30 23:53 ` Maciej W. Rozycki 2014-11-04 11:14 ` Matthew Fortune 0 siblings, 1 reply; 8+ messages in thread From: Maciej W. Rozycki @ 2014-10-30 23:53 UTC (permalink / raw) To: Roland McGrath Cc: Matthew Fortune, Richard Sandiford, binutils, libc-alpha, gdb, Joseph Myers (joseph@codesourcery.com), Moore, Catherine (Catherine_Moore@mentor.com), Nikola Veljkovic 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE 2014-10-30 23:53 ` [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE Maciej W. Rozycki @ 2014-11-04 11:14 ` Matthew Fortune 2014-11-12 23:11 ` Matthew Fortune 0 siblings, 1 reply; 8+ messages in thread From: Matthew Fortune @ 2014-11-04 11:14 UTC (permalink / raw) To: Maciej W. Rozycki, Roland McGrath Cc: Richard Sandiford, binutils, libc-alpha, gdb, Joseph Myers (joseph@codesourcery.com), Moore, Catherine (Catherine_Moore@mentor.com), Nikola Veljkovic 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE 2014-11-04 11:14 ` Matthew Fortune @ 2014-11-12 23:11 ` Matthew Fortune 2014-11-12 23:32 ` Roland McGrath 0 siblings, 1 reply; 8+ messages in thread From: Matthew Fortune @ 2014-11-12 23:11 UTC (permalink / raw) To: Maciej W. Rozycki, Roland McGrath Cc: Richard Sandiford, binutils, libc-alpha, gdb, Joseph Myers (joseph@codesourcery.com), Moore, Catherine (Catherine_Moore@mentor.com), Nikola Veljkovic 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE 2014-11-12 23:11 ` Matthew Fortune @ 2014-11-12 23:32 ` Roland McGrath 2014-11-13 16:37 ` Matthew Fortune 0 siblings, 1 reply; 8+ messages in thread From: Roland McGrath @ 2014-11-12 23:32 UTC (permalink / raw) To: Matthew Fortune Cc: Maciej W. Rozycki, Richard Sandiford, binutils, libc-alpha, gdb, Joseph Myers (joseph@codesourcery.com), Moore, Catherine (Catherine_Moore@mentor.com), Nikola Veljkovic I think it makes sense to define this arch-independent. ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE 2014-11-12 23:32 ` Roland McGrath @ 2014-11-13 16:37 ` Matthew Fortune 2014-11-13 18:00 ` Maciej W. Rozycki 0 siblings, 1 reply; 8+ messages in thread From: Matthew Fortune @ 2014-11-13 16:37 UTC (permalink / raw) To: Roland McGrath Cc: Maciej W. Rozycki, Richard Sandiford, binutils, libc-alpha, gdb, Joseph Myers (joseph@codesourcery.com), Moore, Catherine (Catherine_Moore@mentor.com), Nikola Veljkovic 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE 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 0 siblings, 2 replies; 8+ messages in thread From: Maciej W. Rozycki @ 2014-11-13 18:00 UTC (permalink / raw) To: Matthew Fortune Cc: Roland McGrath, Richard Sandiford, binutils, libc-alpha, gdb, Joseph Myers (joseph@codesourcery.com), Moore, Catherine (Catherine_Moore@mentor.com), Nikola Veljkovic 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE 2014-11-13 18:00 ` Maciej W. Rozycki @ 2014-11-13 19:10 ` Roland McGrath 2014-11-14 11:27 ` Matthew Fortune 1 sibling, 0 replies; 8+ messages in thread From: Roland McGrath @ 2014-11-13 19:10 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Matthew Fortune, Richard Sandiford, binutils, libc-alpha, gdb, Joseph Myers (joseph@codesourcery.com), Moore, Catherine (Catherine_Moore@mentor.com), Nikola Veljkovic > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE 2014-11-13 18:00 ` Maciej W. Rozycki 2014-11-13 19:10 ` Roland McGrath @ 2014-11-14 11:27 ` Matthew Fortune 1 sibling, 0 replies; 8+ messages in thread From: Matthew Fortune @ 2014-11-14 11:27 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Roland McGrath, Richard Sandiford, binutils, libc-alpha, gdb, Joseph Myers (joseph@codesourcery.com), Moore, Catherine (Catherine_Moore@mentor.com), Nikola Veljkovic > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-11-14 11:27 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 ` [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE Maciej W. Rozycki 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).