From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8126 invoked by alias); 8 Feb 2008 18:08:02 -0000 Received: (qmail 8117 invoked by uid 22791); 8 Feb 2008 18:08:01 -0000 X-Spam-Check-By: sourceware.org Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.186) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 08 Feb 2008 18:07:44 +0000 Received: by fk-out-0910.google.com with SMTP id 26so4142729fkx.8 for ; Fri, 08 Feb 2008 10:07:41 -0800 (PST) Received: by 10.82.145.7 with SMTP id s7mr23588887bud.7.1202494061346; Fri, 08 Feb 2008 10:07:41 -0800 (PST) Received: by 10.82.165.12 with HTTP; Fri, 8 Feb 2008 10:07:41 -0800 (PST) Message-ID: <8f2776cb0802081007v3978bbfbs4c91835ddd8c3885@mail.gmail.com> Date: Fri, 08 Feb 2008 18:08:00 -0000 From: "Jim Blandy" To: "Maciej W. Rozycki" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub Cc: "Daniel Jacobowitz" , gdb-patches@sourceware.org, "Maciej W. Rozycki" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080131220315.GC5085@caradoc.them.org> <20080204163929.GA6642@caradoc.them.org> X-Google-Sender-Auth: 001cd6146a03c3df 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/msg00154.txt.bz2 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. [that was weird; sorry] 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. Putting ISA information in low bits of DWARF attribute values isn't the way we've decided to do things.