From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28256 invoked by alias); 8 Feb 2008 14:57:00 -0000 Received: (qmail 28248 invoked by uid 22791); 8 Feb 2008 14:56:59 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 08 Feb 2008 14:56:36 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 5FDBB9814D; Fri, 8 Feb 2008 14:56:33 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 264059810C; Fri, 8 Feb 2008 14:56:33 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JNUeV-00048F-7C; Fri, 08 Feb 2008 09:56:31 -0500 Date: Fri, 08 Feb 2008 14:57:00 -0000 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub Message-ID: <20080208145631.GA14213@caradoc.them.org> Mail-Followup-To: "Maciej W. Rozycki" , gdb-patches@sourceware.org, "Maciej W. Rozycki" References: <20080131220315.GC5085@caradoc.them.org> <20080204163929.GA6642@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) 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/msg00150.txt.bz2 On Fri, Feb 08, 2008 at 02:23:03PM +0000, Maciej W. Rozycki wrote: > > I think that using mips_pc_is_mips16 can be made to work, by analogy > > to ARM. I'd look at this myself, but I don't think I'm set up to run > > 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. Hmm. This sounds believable, but it may react badly with other platforms. We'll have to experiment. > > mips16 tests (yet). Should I be able to do this with just the GDB > > simulator and a board file? > > I have attached the "mips-sim-sde32" board description file I use and the > necessary linker script. You should be able to use it, though there may > be pitfalls. When running tests you need -Wa,-O0 to disable branch > swapping as it makes MIPS16 code inconsistent with DWARF-2 information in > a fatal way. Thanks. > > I don't understand. The stub is not annotated with debug information > > in the example you posted earlier in the thread. It's only "inside > > the block" physically in the assembly file and for the purposes of > > confusing gas (it probably puts the symbol and first instruction in > > different frags, the first of which is zero length, breaking whatever > > gas uses to annotate the symbol value). It's not covered by the range > > [.LFB20, .LEB20] because those labels are in the text section. > > It is still covered by the .loc directive and therefore recognised to be > a part of the code corresponding to the first line of the function. It > makes single-stepping through it possible -- including correct frame > discovery as required by `nexti'/`step'/`next' (not `stepi' though). This makes more sense, but not quite... I see how the .loc covers it. That should get it into .debug_line. However it shouldn't affect the symbol table, or the frame unwinders... I must be missing something, but I'll figure it out eventually. -- Daniel Jacobowitz CodeSourcery