From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28293 invoked by alias); 19 Sep 2008 19:01:43 -0000 Received: (qmail 28283 invoked by uid 22791); 19 Sep 2008 19:01:42 -0000 X-Spam-Check-By: sourceware.org Received: from snape.ecoscentric.com (HELO snape.ecoscentric.com) (212.13.207.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 19 Sep 2008 19:00:43 +0000 Received: from localhost (snape.ecoscentric.com [127.0.0.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 6AE8EDCC250 for ; Fri, 19 Sep 2008 20:00:40 +0100 (BST) Received: from snape.ecoscentric.com ([127.0.0.1]) by localhost (snape.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiGSFJnMV5pa; Fri, 19 Sep 2008 20:00:38 +0100 (BST) Message-ID: <48D3F6D5.30503@eCosCentric.com> Date: Fri, 19 Sep 2008 19:01:00 -0000 From: Jonathan Larmour User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Broken prologue skipping with non-returning function References: <48D3B81B.3000801@eCosCentric.com> <20080919145937.GA1024@caradoc.them.org> In-Reply-To: <20080919145937.GA1024@caradoc.them.org> OpenPGP: id=A5FB74E6 Content-Type: multipart/mixed; boundary="------------080400060703020705020601" Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00114.txt.bz2 This is a multi-part message in MIME format. --------------080400060703020705020601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 2053 Daniel Jacobowitz wrote: > On Fri, Sep 19, 2008 at 03:32:59PM +0100, Jonathan Larmour wrote: >> We end up with a .loc for both lines 6 and 7 with no intervening >> instructions. gdb's symtab.c:find_pc_sect_line() looks for when the pc >> changes to something different and thus ends up returning a symtab_and_line >> indicating that the line at that pc is at the 'if' and runs from the start >> of the function to the ldr after the .loc 1 9 0. > > skip_prologue_using_sal is supposed to detect this. We have a > patch to improve it in our internal tree that we haven't gotten round > to yet. Here it is; I do not remember what the language_asm check was > really about, except that I'm sure it came up running the gdb > testsuite, so removing it and running asm-source.exp would probably > explain it. Thanks! The current arm-tdep.c doesn't presently use skip_prologue_using_sal() however. At a guess that's also lurking in your internal tree, but nevermind, I'm attaching a patch assuming that's useful. With both of these (and my tentative patch reverted) I can confirm it works as expected. If it helps, I have write after approval perms, and a valid current FSF copyright assignment, including disclaimer with my current employer. I noticed I need to update my email address in the MAINTAINERS file which I can do too. I can check in your change too. If so, presumably you already have a ChangeLog entry you'd like me to use to ease your merges? Jifl 2008-09-19 Jonathan Larmour * arm-tdep.c (arm_skip_prologue): Call skip_prologue_using_sal instead of determining symbol and line info directly. -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine >>>> Visit us on stand 905 at the Embedded Systems Show 2008 <<<< >>>> Oct 1-2, NEC, Birmingham, UK http://www.embedded.co.uk <<<< --------------080400060703020705020601 Content-Type: text/x-patch; name="arm.skip.prologue.using.sal.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="arm.skip.prologue.using.sal.patch" Content-length: 2441 --- arm-tdep.c.old 2008-09-19 17:01:32.000000000 +0100 +++ arm-tdep.c 2008-09-19 17:23:42.000000000 +0100 @@ -519,43 +519,40 @@ arm_skip_prologue (struct gdbarch *gdbar { unsigned long inst; CORE_ADDR skip_pc; - CORE_ADDR func_addr, func_end = 0; - char *func_name; + CORE_ADDR func_addr, limit_pc; struct symtab_and_line sal; /* If we're in a dummy frame, don't even try to skip the prologue. */ if (deprecated_pc_in_call_dummy (pc)) return pc; - /* See what the symbol table says. */ - - if (find_pc_partial_function (pc, &func_name, &func_addr, &func_end)) - { - struct symbol *sym; - - /* Found a function. */ - sym = lookup_symbol (func_name, NULL, VAR_DOMAIN, NULL); - if (sym && SYMBOL_LANGUAGE (sym) != language_asm) - { - /* Don't use this trick for assembly source files. */ - sal = find_pc_line (func_addr, 0); - if ((sal.line != 0) && (sal.end < func_end)) - return sal.end; - } - } - - /* Can't find the prologue end in the symbol table, try it the hard way - by disassembling the instructions. */ - + /* See if we can determine the end of the prologue via the symbol table. + If so, then return either PC, or the PC after the prologue, whichever + is greater. */ + if (find_pc_partial_function (pc, NULL, &func_addr, NULL)) + { + CORE_ADDR post_prologue_pc = skip_prologue_using_sal (func_addr); + if (post_prologue_pc != 0) + return max (pc, post_prologue_pc); + } + + /* Can't determine prologue from the symbol table, need to examine + instructions. */ + + /* Find an upper limit on the function prologue using the debug + information. If the debug information could not be used to provide + that bound, then use an arbitrary large number as the upper bound. */ /* Like arm_scan_prologue, stop no later than pc + 64. */ - if (func_end == 0 || func_end > pc + 64) - func_end = pc + 64; + limit_pc = skip_prologue_using_sal (pc); + if (limit_pc == 0) + limit_pc = pc + 64; /* Magic. */ + /* Check if this is Thumb code. */ if (arm_pc_is_thumb (pc)) - return thumb_analyze_prologue (gdbarch, pc, func_end, NULL); + return thumb_analyze_prologue (gdbarch, pc, limit_pc, NULL); - for (skip_pc = pc; skip_pc < func_end; skip_pc += 4) + for (skip_pc = pc; skip_pc < limit_pc; skip_pc += 4) { inst = read_memory_unsigned_integer (skip_pc, 4); --------------080400060703020705020601--