From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7056 invoked by alias); 12 Apr 2002 09:51:59 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7043 invoked from network); 12 Apr 2002 09:51:56 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sources.redhat.com with SMTP; 12 Apr 2002 09:51:56 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (8.9.3/8.8.7) with ESMTP id LAA24328; Fri, 12 Apr 2002 11:51:44 +0200 Message-Id: <4.2.0.58.20020412113413.01df5798@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr Date: Fri, 12 Apr 2002 02:51:00 -0000 To: Daniel Jacobowitz , gdb@sources.redhat.com From: Pierre Muller Subject: Re: Further problem with 2.95.3 debug info :( In-Reply-To: <20020411221143.A2000@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2002-04/txt/msg00204.txt.bz2 At 04:11 12/04/2002 , Daniel Jacobowitz a écrit: >This one isn't as easy as the last stabs fix. Sometimes, apparently, GCC >elides the first line number instead of shifting it later. As a result, >breakpoints on the function now stop in a yet wronger location. Example: The reason is that there is a addl -12,%esp that is probably still interpreted as being part of the function prologue. This lead to thefact that GDB thinks that the real start of code (without prologue) is at pushl $toplevel but that one is in the middle of a line block, so GDB decides to move to the start of next line, assuming the the rest of the line must also be part of the prologue... I ran into the same problem with Free Pascal object code: If a pascal object (which is allmost a C++ class) calls a method of itself as the first statement of a method function, then the compiler adds a pusl %esi because %esi contains the address of the object but if the called method has no argument, then this instruction just follows the push %ebp mov %esp,%ebp subl $xxx,%esp prologue and i386_skip_prologue then interprets the pushl %esi as part of the prologue and does the same error as for this C code. >main: >.LBB10: > pushl %ebp > movl %esp,%ebp > subl $2044,%esp > pushl %edi > pushl %esi > pushl %ebx >.stabn 68,0,90,.LM21-main >.LM21: > addl $-12,%esp > pushl $toplevel > call _setjmp > addl $16,%esp > testl %eax,%eax > je .L174 >.stabn 68,0,92,.LM22-main >.LM22: > >So we break after the first call to setjmp. Which is, the astute observer >notes, inside of an `if'. In this case, it's a not-usually-taken `if' and >we stop at the completely wrong time. > >There's no fixing this with the debug info we have, IMO. GCC 3.0 gets the >debug info right and we then handle it correctly. I've no idea what prompts >GCC to do which (although it seems to show up more on PowerPC than on i386, >I've seen it on both). > >So, this message is just in case anyone has a brilliant idea for handling >this, or to save people a little time on bug reports. The only thing I can >think of is to let a prologue scanner hit the panic button and say "no, the >prologue really DOES end between lines!". This can be disabled by defining PROLOGUE_FIRSTLINE_OVERLAP in find_function_start_sal () function of symtab.c #ifdef PROLOGUE_FIRSTLINE_OVERLAP /* Convex: no need to suppress code on first line, if any */ sal.pc = pc; #else /* Check if SKIP_PROLOGUE left us in mid-line, and the next line is still part of the same function. */ if (sal.pc != pc && BLOCK_START (SYMBOL_BLOCK_VALUE (sym)) <= sal.end && sal.end < BLOCK_END (SYMBOL_BLOCK_VALUE (sym))) { /* First pc of next line */ pc = sal.end; /* Recalculate the line number (might not be N+1). */ sal = find_pc_sect_line (pc, SYMBOL_BFD_SECTION (sym), 0); } sal.pc = pc; #endif and in step_into_function () of infrun.c #ifdef PROLOGUE_FIRSTLINE_OVERLAP /* no, don't either. It skips any code that's legitimately on the first line. */ #else if (ecs->sal.end && ecs->sal.pc != ecs->stop_func_start && ecs->sal.end < ecs->stop_func_end) ecs->stop_func_start = ecs->sal.end; #endif Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99