This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Further problem with 2.95.3 debug info :(

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
   push %ebp
   mov %esp,%ebp
   subl $xxx,%esp
and i386_skip_prologue
then interprets the pushl %esi as part of the prologue
and does the same error as for this C code.

>         pushl %ebp
>         movl %esp,%ebp
>         subl $2044,%esp
>         pushl %edi
>         pushl %esi
>         pushl %ebx
>.stabn 68,0,90,.LM21-main
>         addl $-12,%esp
>         pushl $toplevel
>         call _setjmp
>         addl $16,%esp
>         testl %eax,%eax
>         je .L174
>.stabn 68,0,92,.LM22-main
>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

in find_function_start_sal () function of symtab.c 

   /* Convex: no need to suppress code on first line, if any */
   sal.pc = pc;
   /* 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;

and in step_into_function () of infrun.c

   /* no, don't either.  It skips any code that's legitimately on the
      first line.  */
   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;

Pierre Muller
Institut Charles Sadron
6,rue Boussingault
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]