From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6700 invoked by alias); 1 Feb 2008 16:58:05 -0000 Received: (qmail 32248 invoked by uid 22791); 1 Feb 2008 16:54:45 -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, 01 Feb 2008 16:54:15 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 6468298234; Fri, 1 Feb 2008 16:54:13 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 00D2B98217; Fri, 1 Feb 2008 16:54:12 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JKz9X-0001G6-Qw; Fri, 01 Feb 2008 11:54:11 -0500 Date: Fri, 01 Feb 2008 16:58:00 -0000 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: Thiemo Seufer , gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub Message-ID: <20080201165411.GA4063@caradoc.them.org> Mail-Followup-To: "Maciej W. Rozycki" , Thiemo Seufer , gdb-patches@sourceware.org, "Maciej W. Rozycki" References: <20080131220315.GC5085@caradoc.them.org> <20080201141838.GB28371@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/msg00019.txt.bz2 On Fri, Feb 01, 2008 at 03:34:04PM +0000, Maciej W. Rozycki wrote: > On Fri, 1 Feb 2008, Daniel Jacobowitz wrote: > > > > The other way round -- the minimal symbol points to the actual entry > > > point, but the stub precedes it and is included in the DWARF-2 block > > > together with the MIPS16 function body. Here's an example that triggers a > > > failure in the test suite (generated from gdb.base/call-ar-st.c by GCC > > > 4.2.2): > > > > Then why aren't we calling the instruction at the start of the block, > > i.e. the stub? In which case not using the MIPS16 convention is > > correct. I don't see why you'd want to call > > __fn_stub_print_ten_doubles as a MIPS16 function. > > Well, GDB does not ever seem to call the stub. That's because I didn't notice the section switch in your example. The stub is not part of the block described in the DWARF-2 table; it's physically between the labels in the assembly file, but the labels are in the text section and the stub isn't. So that's why we call the real function. One confusion solved. > <1>: Abbrev Number: 16 (DW_TAG_subprogram) > DW_AT_external : 1 > DW_AT_name : print_ten_doubles > DW_AT_decl_file : 1 > DW_AT_decl_line : 664 > DW_AT_low_pc : 0x80020a90 > DW_AT_high_pc : 0x80020b00 > DW_AT_frame_base : 0x306 (location list) > DW_AT_sibling : > > I have done a little more research of this matter now and it looks like > the reason this is happening is a likely bug somewhere in GAS. For > comparison, here are the unrelocated DWARF-2 records for > print_ten_doubles() and a nearby function that has no stub: > > <1>: Abbrev Number: 16 (DW_TAG_subprogram) > DW_AT_external : 1 > DW_AT_name : init_small_structs > DW_AT_decl_file : 1 > DW_AT_decl_line : 613 > DW_AT_low_pc : 0x790 > DW_AT_high_pc : 0x900 > DW_AT_frame_base : 0x2db (location list) > DW_AT_sibling : <0xcaf> > > <1>: Abbrev Number: 16 (DW_TAG_subprogram) > DW_AT_external : 1 > DW_AT_name : print_ten_doubles > DW_AT_decl_file : 1 > DW_AT_decl_line : 664 > DW_AT_low_pc : 0x900 > DW_AT_high_pc : 0x97c > DW_AT_frame_base : 0x306 (location list) > DW_AT_sibling : <0xd66> > > And here are the relevant relocation records: > > 00000bc3 00003c02 R_MIPS_32 00000790 .LFB23 > 00000bc7 00000202 R_MIPS_32 00000000 .text > > 00000cc6 00000202 R_MIPS_32 00000000 .text > 00000cca 00000202 R_MIPS_32 00000000 .text > > Notice that the DWARF-2 record at 0xbc3 is relocated against .LFB23 and > one at 0xcc6 -- against .text, rather than .LFB20 as it should be. I > presume this is because of the section switch happening inbetween. Or > could it be because of ".set nomips16" actually preceding the section > switch? Thiemo, can you perhaps make any comments about this? Does the low bit end up set in the DWARF for init_small_structs? From what you're saying, I think it does. My experience with Thumb makes me think that's the actual GAS bug here. Those are code addresses, not symbols, and I don't think they should encode MIPS16-ness - see the recent discussion of values in .debug_line, which we agreed should not have assorted flag bits set either. The code starts at 0x900, not 0x901. -- Daniel Jacobowitz CodeSourcery