From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14382 invoked by alias); 1 Feb 2008 15:34:35 -0000 Received: (qmail 14367 invoked by uid 22791); 1 Feb 2008 15:34:34 -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; Fri, 01 Feb 2008 15:34:16 +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 1JKxu9-00022k-00; Fri, 01 Feb 2008 15:34:13 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1JKxu0-0003jr-00; Fri, 01 Feb 2008 15:34:04 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1JKxu0-0007mR-1a; Fri, 01 Feb 2008 15:34:04 +0000 Date: Fri, 01 Feb 2008 15:34:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz , Thiemo Seufer cc: gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub In-Reply-To: <20080201141838.GB28371@caradoc.them.org> Message-ID: References: <20080131220315.GC5085@caradoc.them.org> <20080201141838.GB28371@caradoc.them.org> 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/msg00014.txt.bz2 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. I have not written code responsible for this, but I can see two possible reasons: 1. Simplicity -- depending on the callers of the function in question there may be no stub. If there are no standard MIPS callers, then the stub is stripped out by the linker. 2. Performance -- the stub is a couple of additional instructions to execute which buy you nothing when called from GDB as it may load the correct argument registers according to the ABI in the first place. And as I wrote the block associated with print_ten_doubles() does not span __fn_stub_print_ten_doubles() -- I may have not been clear enough about this being the case for the DWARF-2 record. This is what GDB has to say about the function (with the fix applied): (gdb) print print_ten_doubles $1 = {void (double, double, double, double, double, double, double, double, double, double)} 0x80020a91 (gdb) print __fn_stub_print_ten_doubles $2 = {} 0x800283d0 <__fn_stub_print_ten_doubles> And this is what the relevant DWARF-2 record holds: <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? I do not know how long this bug has been there in GAS, but it may still be worth handling broken binaries people may have. Then again -- maybe not. But we have no fix for GAS as yet. Regardless I have not made a strong opinion either way. Maciej