Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Further problem with 2.95.3 debug info :(
@ 2002-04-11 19:11 Daniel Jacobowitz
  2002-04-12  2:51 ` Pierre Muller
  0 siblings, 1 reply; 2+ messages in thread
From: Daniel Jacobowitz @ 2002-04-11 19:11 UTC (permalink / raw)
  To: gdb

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:

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!".

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Further problem with 2.95.3 debug info :(
  2002-04-11 19:11 Further problem with 2.95.3 debug info :( Daniel Jacobowitz
@ 2002-04-12  2:51 ` Pierre Muller
  0 siblings, 0 replies; 2+ messages in thread
From: Pierre Muller @ 2002-04-12  2:51 UTC (permalink / raw)
  To: Daniel Jacobowitz, gdb

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-04-12  9:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-11 19:11 Further problem with 2.95.3 debug info :( Daniel Jacobowitz
2002-04-12  2:51 ` Pierre Muller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox