From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7819 invoked by alias); 4 Nov 2014 11:14:15 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 7783 invoked by uid 89); 4 Nov 2014 11:14:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 3 recipients X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Nov 2014 11:14:11 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 2E5637EBAE9FB; Tue, 4 Nov 2014 11:14:07 +0000 (GMT) Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 4 Nov 2014 11:14:09 +0000 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0210.002; Tue, 4 Nov 2014 11:14:08 +0000 From: Matthew Fortune To: "Maciej W. Rozycki" , Roland McGrath CC: Richard Sandiford , "binutils@sourceware.org" , "libc-alpha@sourceware.org" , "gdb@sourceware.org" , "Joseph Myers (joseph@codesourcery.com)" , "Moore, Catherine (Catherine_Moore@mentor.com)" , Nikola Veljkovic Subject: RE: [RFC][MIPS] What to do about DT_MIPS_RLD_MAP and PIE Date: Tue, 04 Nov 2014 11:14:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B0235320F6A03C@LEMAIL01.le.imgtec.org> References: <6D39441BF12EF246A7ABCE6654B0235320F3027E@LEMAIL01.le.imgtec.org> <6D39441BF12EF246A7ABCE6654B0235320F30462@LEMAIL01.le.imgtec.org> <871tpy37ir.fsf@googlemail.com> <6D39441BF12EF246A7ABCE6654B0235320F385FA@LEMAIL01.le.imgtec.org> <20141030193816.E80F82C3B18@topped-with-meat.com> In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00002.txt.bz2 Maciej W. Rozycki writes: > On Thu, 30 Oct 2014, Roland McGrath wrote: >=20 > > > 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? >=20 > Here's what the 32-bit MIPS psABI[1] says about it: >=20 > "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." >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 >=20 > References: >=20 > [1] "SYSTEM V APPLICATION BINARY INTERFACE, MIPS RISC Processor > Supplement, 3rd Edition" > http://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf >=20 > [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 >=20 > Maciej