From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30138 invoked by alias); 13 Feb 2008 18:28:39 -0000 Received: (qmail 30126 invoked by uid 22791); 13 Feb 2008 18:28: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; Wed, 13 Feb 2008 18:28:11 +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 1JPML0-0007Ix-00; Wed, 13 Feb 2008 18:28:06 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1JPMKu-00015t-00; Wed, 13 Feb 2008 18:28:00 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1JPMKu-0001Zi-5X; Wed, 13 Feb 2008 18:28:00 +0000 Date: Wed, 13 Feb 2008 18:28:00 -0000 From: "Maciej W. Rozycki" To: Jim Blandy cc: Daniel Jacobowitz , gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub In-Reply-To: <8f2776cb0802081007v3978bbfbs4c91835ddd8c3885@mail.gmail.com> Message-ID: References: <20080131220315.GC5085@caradoc.them.org> <20080204163929.GA6642@caradoc.them.org> <8f2776cb0802081007v3978bbfbs4c91835ddd8c3885@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/msg00214.txt.bz2 On Fri, 8 Feb 2008, Jim Blandy wrote: > On Feb 8, 2008 6:23 AM, Maciej W. Rozycki wrote: > > It is much more than that, but I think it can be done with some > > adjustments to pointer_to_address(), address_to_pointer() and > > integer_to_address() methods. If DWARF-2 records could be treated as > > pointers (which they are given how the linker processes them) rather than > > addresses then such a setup should work. That should be done above the > > level of the DWARF-2 interpreter, as losing the LSB from relative data > > often contained in records would result in an accumulative error. > > If you're suggesting that we run the values in DWARF data through > pointer_to_address, I don't think that's right, either. DWARF > specifies that those attributes' values are byte addresses of code. You are right indeed -- this is what the spec says: "address Represented as an object of appropriate size to hold an address on the target machine (DW_FORM_addr). The size is encoded in the compilation unit header (see Section 7.5.1). This address is relocatable in a relocatable object file and is relocated inan executable file or shared object." > Putting ISA information in low bits of DWARF attribute values isn't > the way we've decided to do things. Unfortunately this is what the current versions of the relevant tools do and I think it has been like this for a while. The linker does not differentiate between relocations used for taking an address of a function for the purpose of making a call and for other uses and the same relocation types are used in both cases. Ultimately it is the linker that should be fixed (though from the current behaviour I think GAS has a problem here as well), but I am afraid broken tools and broken binaries are going to be out there for a while yet, so it may be a reasonable idea to try to handle them as well as possible. I recognise pointer_to_address() may not be the best choice here though. However I think it will have to be involved anyway elsewhere as I find the current model assumed by GDB inconsistent. Maciej