From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4533 invoked by alias); 15 Feb 2008 11:36:41 -0000 Received: (qmail 4522 invoked by uid 22791); 15 Feb 2008 11:36:40 -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; Fri, 15 Feb 2008 11:36:23 +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 1JPyrW-0004PL-00; Fri, 15 Feb 2008 11:36:14 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1JPyrN-0006G4-00; Fri, 15 Feb 2008 11:36:05 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1JPyrN-0003GH-PN; Fri, 15 Feb 2008 11:36:05 +0000 Date: Fri, 15 Feb 2008 11:36:00 -0000 From: "Maciej W. Rozycki" To: Jim Blandy cc: Daniel Jacobowitz , Nigel Stephens , gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub In-Reply-To: <8f2776cb0802131254p7fd04ba5lf908414940b7f622@mail.gmail.com> Message-ID: References: <20080131220315.GC5085@caradoc.them.org> <20080204163929.GA6642@caradoc.them.org> <8f2776cb0802081007v3978bbfbs4c91835ddd8c3885@mail.gmail.com> <8f2776cb0802131254p7fd04ba5lf908414940b7f622@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com 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/msg00252.txt.bz2 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. > > - The addresses in GDB's line tables and block ranges should not have > such extra bits set in them. > > - 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. > 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). 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