From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5745 invoked by alias); 13 Feb 2008 20:54:47 -0000 Received: (qmail 5731 invoked by uid 22791); 13 Feb 2008 20:54:46 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.191) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Feb 2008 20:54:29 +0000 Received: by nf-out-0910.google.com with SMTP id b11so101265nfh.48 for ; Wed, 13 Feb 2008 12:54:26 -0800 (PST) Received: by 10.82.187.2 with SMTP id k2mr758092buf.19.1202936065839; Wed, 13 Feb 2008 12:54:25 -0800 (PST) Received: by 10.82.162.12 with HTTP; Wed, 13 Feb 2008 12:54:25 -0800 (PST) Message-ID: <8f2776cb0802131254p7fd04ba5lf908414940b7f622@mail.gmail.com> Date: Wed, 13 Feb 2008 20:54: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> <8f2776cb0802081007v3978bbfbs4c91835ddd8c3885@mail.gmail.com> X-Google-Sender-Auth: 41e50a04c2ca77bb 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/msg00215.txt.bz2 On Feb 13, 2008 10:27 AM, Maciej W. Rozycki wrote: > On Fri, 8 Feb 2008, Jim Blandy wrote: > > 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. 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. 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. 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. :)