From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19746 invoked by alias); 18 Feb 2008 13:32:40 -0000 Received: (qmail 19691 invoked by uid 22791); 18 Feb 2008 13:32:38 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Feb 2008 13:32:21 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1JR66R-0001iZ-00; Mon, 18 Feb 2008 13:32:15 +0000 Received: from ukcvpn35.mips-uk.com ([192.168.193.35]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1JR66H-0008FO-00; Mon, 18 Feb 2008 13:32:05 +0000 Message-ID: <47B988D5.3060605@mips.com> Date: Mon, 18 Feb 2008 13:32:00 -0000 From: Nigel Stephens User-Agent: IceDove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Jim Blandy , Daniel Jacobowitz , gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub References: <20080131220315.GC5085@caradoc.them.org> <20080204163929.GA6642@caradoc.them.org> <8f2776cb0802081007v3978bbfbs4c91835ddd8c3885@mail.gmail.com> <8f2776cb0802131254p7fd04ba5lf908414940b7f622@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.com X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00287.txt.bz2 Sorry if I repeat anything -- I've not been copied on this conversation until now. Maciej W. Rozycki wrote: > On Wed, 13 Feb 2008, Jim Blandy wrote: > > >> It seems that we all agree on the following: >> >> - It's contrary to the DWARF spec for producers to put arch-specific >> information in the low bits of the addresses in the line number >> table, function and block address ranges, and so on. Existing >> toolchains that do this are buggy, but that's life. >> Hmm. The ELF symbol table has an "out of band" mechanism to distinguish symbols which refer to different architectural encodings, using the architecture-specific bits in the st_info field. But how would you represent that in DWARF's object file encoding, noting that the "MIPS16-ness" of an undefined symbol is not known at compile time, only at final link time. And this is not just a way of sneaking architecture-specific "information" through the object file: it is a fundamental aspect of the MIPS architecture. From the running software's point of view bit 0 of the PC must be set to execute MIPS16 instructions (e.g. when performing an indirect jump or function call) and it will always be viewed as set when made visible to software (e.g. in the return address register after a function call, or saved on the stack, or in the exception program counter). Bit 0 must therefore be set in any data which points to a MIPS16 instruction. Because of the way that DWARF information is generated using assembler directives, then by the time a program is fully linked bit 0 of a to a MIPS16 address within a DWARF section will "by definition" be set: it would otherwise not be a valid pointer to a MIPS16 instruction. I suppose that we could invent new relocation types for DWARF data, or get the linker to relocate data within .dwarf* sections differently, but that would be an intrusive change. >> - The addresses in GDB's line tables and block ranges should not have >> such extra bits set in them. >> Well, I suppose that you could clear bit 0, after stashing it in some other field of the line table or block range. But you'd then have to make sure that it continued to be passed around, along with the address -- or else at some point you'd have to fold it back into bit0 of the address anyway. >> - The proper place to store arch-specific data on minimal symbols is >> in the 'info' field of 'struct minimal_symbol'. In cases like >> MIPS16, the gdbarch_push_dummy_call method can consult that >> information at call time to see which calling convention is >> appropriate. >> > > I certainly agree here. > What about when there isn't an ELF symbol associated with an address? > >> If we agree that we want to work around the linker bugs in GDB's >> reader, that means we have to clear those bits and stash the >> information elsewhere when we read the DWARF. So something like >> Maciej's original patch doesn't seem wrong to me. >> > > OK, but the original patch does not clear the bit, but actually it sets > it in the single case discovered so far where GAS gets it wrong (and > linker does not fix up in any way). Maybe fix GAS then? Maciej, can you provide example assembler code that GAS handles incorrectly? > What I attempted meanwhile was to > adjust the DWARF reader so that it effectively ignores the bit. It proved > not as straightforward as it could immediately be thought it would be as > with some structures addresses are calculated cumulatively and one or more > addends may be odd. It is therefore necessary, where applicable, not only > to mask out the LSB, but also to remember its value and carry it forward > to the next addition. > > What I have developed is a crude hack as a proof of concept which just > does all the extra calculation unconditionally so that I could verify it > was at all workable as well as identify all the places that would have to > be changed and how. If there is agreement to push this approach forward I > will have a look at how to do this properly. > > >> The name 'make_symbol_special' seems awfully vague, though. Is the >> term 'special' inherited from outside GDB, or did it originate within >> GDB? In either case, I don't want it propagating into the DWARF >> reader; that's horrible. :) >> > > I have just derived an arbitrary name from make_msymbol_special. No > preference either way, but I gather this is not the way we want to go > anyway. > > Maciej > -- Nigel Stephens | MIPS Technologies (UK) | t:(+44|0)1223 203110 Technical Director | 7200 Cambridge Research Pk | f:(+44|0)1223 203181 . | Cambridge, England CB25 9TL | c:(+44|0)7976 686470