From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6716 invoked by alias); 30 Oct 2014 23:53:30 -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 6682 invoked by uid 89); 30 Oct 2014 23:53:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 3 recipients X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Oct 2014 23:53:27 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XjzWs-0003qb-Fw from Maciej_Rozycki@mentor.com ; Thu, 30 Oct 2014 16:53:22 -0700 Received: from localhost (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 23:53:20 +0000 Date: Thu, 30 Oct 2014 23:53:00 -0000 From: "Maciej W. Rozycki" To: Roland McGrath CC: Matthew Fortune , Richard Sandiford , , , , "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 In-Reply-To: <20141030193816.E80F82C3B18@topped-with-meat.com> Message-ID: 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> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-10/txt/msg00137.txt.bz2 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