[RFC] Is skip_prologue_using_sal actually usable?

[RFC] Is skip_prologue_using_sal actually usable?

[Mark Kettenis]

It defenitely has bugs; if the compiler only generates a single line
table entry for a function, it will skip the entire function.  That
can easily be fixed by the attached patch, but it seems we're really
confused with what skipping the prologue should actually do.  It seems
that in some instances we implement:

1. Skip instructions from the start of the function until we encounter
   the first instruction that doesn't belong to the prologue.

while in other cases we implement:

2. Skip instructions from the start of the function until we have seen
   all instructions belonging to the prologue.

Back in the old days, when prologues were fixed, 1 and 2 were pretty
much equivalent.  However, these days, with compilers migrating many
instructions into the prologue, the difference can be huge, and making
the wrong choice can be very annoying.

Core GDB code seems to use skipping the prologue for a single purpose:
determining the first line with "real code" of a function, to place a
breakpoint at that location or to determine where it should stop when
stepping into a function.  For this purpose I argue that we should
implement 1 instead of 2.  Implementing 2 means that we run the risk
of skipping interesting code.  If that code contains a branch, things
really break down because it means that GDB might never actually stop
in a function on which the user placed a breakpoint, or that GDB will
run until the program exits if you step into a function.

The drawback of implementation 1 is mainly that the prologue isn't
completely finished when GDB stops.  This means that GDB might not
print function arguments correctly because the stack frame hasn't been
fully setup yet.

The problem we're facing here's that our testsuite has many tests that
break down if we skip to little but almost none that break down if we
skip too much.  However, in real life, it's better to skip too little
than to much, as I argued above.

Things are complicated further by trying to skip the prologue by using
line number information.  Some compilers generate line number info for
the first instruction of a function, others don't.  In addition to
that, compilers generate buggy line number info.  It seems that
everytime GCC gains a new optimization that moves more stuff into the
prologue, the line number info generated for these instructions isn't
quite right.  As such, I think we should be very conservative when
skipping prologues solely using line number info, stopping at the line
containing the lowest address instead of the lowest line number as
skip_prologue_using_sal does.

Thoughts?

Mark


Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.141
diff -u -p -r1.141 symtab.c
--- symtab.c 22 Oct 2004 20:58:56 -0000 1.141
+++ symtab.c 7 Nov 2004 13:45:55 -0000
@@ -4050,6 +4050,11 @@ skip_prologue_using_sal (CORE_ADDR func_
 	  prologue_sal = sal;
 	}
     }
+
+  /* Avoid skipping the entire function.  */
+  if (prologue_sal.end >= end_pc)
+    return 0;
+
   return prologue_sal.end;
 }
 \f

Re: [RFC] Is skip_prologue_using_sal actually usable?

[Randolph Chung]

> It defenitely has bugs; if the compiler only generates a single line
> table entry for a function, it will skip the entire function.  

fwiw hppa-tdep.c has this workaround/bugfix as well....

> Back in the old days, when prologues were fixed, 1 and 2 were pretty
> much equivalent.  However, these days, with compilers migrating many
> instructions into the prologue, the difference can be huge, and making
> the wrong choice can be very annoying.

i was just debugging a problem today with stack unwinding on hppa when i
saw this... this is exactly the problem! :-(

> The drawback of implementation 1 is mainly that the prologue isn't
> completely finished when GDB stops.  This means that GDB might not
> print function arguments correctly because the stack frame hasn't been
> fully setup yet.

it will also not unwind properly (on hppa) because we cannot find the
previous functions pc and sp. the hppa target has some code to skip the
prologue in a different way if line number information is not available,
but when it is available we use it, causing unwinding to fail.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [RFC] Is skip_prologue_using_sal actually usable?

[Daniel Jacobowitz]

On Sun, Nov 07, 2004 at 02:55:41PM +0100, Mark Kettenis wrote:
> The drawback of implementation 1 is mainly that the prologue isn't
> completely finished when GDB stops.  This means that GDB might not
> print function arguments correctly because the stack frame hasn't been
> fully setup yet.
> 
> The problem we're facing here's that our testsuite has many tests that
> break down if we skip to little but almost none that break down if we
> skip too much.  However, in real life, it's better to skip too little
> than to much, as I argued above.
> 
> Things are complicated further by trying to skip the prologue by using
> line number information.  Some compilers generate line number info for
> the first instruction of a function, others don't.  In addition to
> that, compilers generate buggy line number info.  It seems that
> everytime GCC gains a new optimization that moves more stuff into the
> prologue, the line number info generated for these instructions isn't
> quite right.  As such, I think we should be very conservative when
> skipping prologues solely using line number info, stopping at the line
> containing the lowest address instead of the lowest line number as
> skip_prologue_using_sal does.
> 
> Thoughts?

If you want the first instruction that is not part of the prologue,
then you have no more reason to skip prologues at all.  My
understanding is that prologue skipping accomplishes two things:

  - Get the arguments into their save slots so that we can find
    and display them.

  - Get the frame pointer into a sane state so we can backtrace.

Well, we've taken care of (A) already - the new frame code requires
being able to backtrace from the first instruction of a function,
and we do it.  (I think we fall down more often in the epilogue than we
do in the prologue now.)

What we need is a coherent approach to (B).  Future versions of GCC
will make this much easier, by emitting location lists.  But for
existing code, and non-dwarf2 targets, I think we could do better than
we do now.  Here's a possible approach.

We'd need a gdbarch method describing where incoming arguments were
placed.  This could be unified with the function calling code -
cleanest might be to implement a proper "location" data type and then
have the code return a list of locations to either store the parameters
or fetch them depending on context.  Then, we'd need a modified sort of
prologue analyzer that told us whether the incoming location for a
particular parameter was likely still valid, or whether the
debug-info-provided location had been initialized.  With enough
architecture-independent support code, instead of cramming it all into
the backend, I think this would not be terribly complicated either.

Then, when we arrive at a function - from the very first instruction -
we can display arguments correctly.  The user doesn't have to worry
about the copy.

How does that sound?  Pipe dream?

-- 
Daniel Jacobowitz

Re: [RFC] Is skip_prologue_using_sal actually usable?

[Mark Kettenis]

   Date: Mon, 8 Nov 2004 21:43:14 -0500
   From: Daniel Jacobowitz <drow@false.org>

   If you want the first instruction that is not part of the prologue,
   then you have no more reason to skip prologues at all.  My
   understanding is that prologue skipping accomplishes two things:

B?   - Get the arguments into their save slots so that we can find
       and display them.

A?   - Get the frame pointer into a sane state so we can backtrace.

   Well, we've taken care of (A) already - the new frame code requires
   being able to backtrace from the first instruction of a function,
   and we do it.  (I think we fall down more often in the epilogue than we
   do in the prologue now.)

Assuming the second point is (A) and the first one is (B):

There are still problems here on some badly maintained archs, but in
general this should be OK.  We currently make no effort on getting
things right for the epilogue.

   What we need is a coherent approach to (B).  Future versions of GCC
   will make this much easier, by emitting location lists.  But for
   existing code, and non-dwarf2 targets, I think we could do better than
   we do now.  Here's a possible approach.

   We'd need a gdbarch method describing where incoming arguments were
   placed.  This could be unified with the function calling code -
   cleanest might be to implement a proper "location" data type and then
   have the code return a list of locations to either store the parameters
   or fetch them depending on context.  Then, we'd need a modified sort of
   prologue analyzer that told us whether the incoming location for a
   particular parameter was likely still valid, or whether the
   debug-info-provided location had been initialized.  With enough
   architecture-independent support code, instead of cramming it all into
   the backend, I think this would not be terribly complicated either.

   Then, when we arrive at a function - from the very first instruction -
   we can display arguments correctly.  The user doesn't have to worry
   about the copy.

   How does that sound?  Pipe dream?

Although it sounds plausible I think it's something we should revisit
when GDB actually supports "locations" properly.

In the mean time, we really should strive for some consistency in
where we put function breakpoints.  What do you think about my
statement that too early is better than to late?

Mark

Re: [RFC] Is skip_prologue_using_sal actually usable?

[Daniel Jacobowitz]

On Tue, Nov 09, 2004 at 02:53:20PM +0100, Mark Kettenis wrote:
>    Date: Mon, 8 Nov 2004 21:43:14 -0500
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    If you want the first instruction that is not part of the prologue,
>    then you have no more reason to skip prologues at all.  My
>    understanding is that prologue skipping accomplishes two things:
> 
> B?   - Get the arguments into their save slots so that we can find
>        and display them.
> 
> A?   - Get the frame pointer into a sane state so we can backtrace.
> 
>    Well, we've taken care of (A) already - the new frame code requires
>    being able to backtrace from the first instruction of a function,
>    and we do it.  (I think we fall down more often in the epilogue than we
>    do in the prologue now.)
> 
> Assuming the second point is (A) and the first one is (B):

Oops -)  Yes, that's what I meant.

> Although it sounds plausible I think it's something we should revisit
> when GDB actually supports "locations" properly.
> 
> In the mean time, we really should strive for some consistency in
> where we put function breakpoints.  What do you think about my
> statement that too early is better than to late?

I don't think I agree.  We used to have a lot of problems with placing
breakpoints after branches; that, obviously, is too late (excepting the
PIC register setup).  But I find the inaccuracy of displayed function
arguments to be my single biggest day-to-day problem in using GDB. 
Just moments ago I wasted a couple minutes discovering that a pointer
hadn't been saved to the stack yet.

-- 
Daniel Jacobowitz

Re: [RFC] Is skip_prologue_using_sal actually usable?

[Andrew Cagney]

Mark,

DWARF 2 provides us with the exact location[s] of a prologue end, can we 
use that?

skip_prologue, just like the traditional unwinder, only has to be ``good 
enough''.

Andrew

Re: [RFC] Is skip_prologue_using_sal actually usable?

[Mark Kettenis]

   Date: Tue, 09 Nov 2004 09:50:27 -0500
   From: Andrew Cagney <cagney@gnu.org>

   Mark,

   DWARF 2 provides us with the exact location[s] of a prologue end, can we 
   use that?

DW_LNS_set_prologue_end is a DWARF3 thingy, which GCC doesn't generate
yet.  The DWARF3 definition seems to match exactly what I have in mind
though.

   skip_prologue, just like the traditional unwinder, only has to be ``good 
   enough''.

The problem here is that we as devlopers don't seem to agree on what
we mean by "good enough".  As a result, the implementations in GDB
vary wildly throughout GDB.

The concrete problem I'm facing here is that skip_prologue_using_sal
as used by mips-tdep.c doesn't work for me on OpenBSD/mips64.  It can
be fixed by applying the patch in the message that started this
thread, but if an implementation only has to be "good enough", I think
skip_prologue_using_sal is actually doing to much.  Something like the
following code would be better:

static CORE_ADDR
sparc32_skip_prologue (CORE_ADDR start_pc)
{
  struct symtab_and_line sal;
  CORE_ADDR func_start, func_end;
  struct sparc_frame_cache cache;

  /* This is the preferred method, find the end of the prologue by
     using the debugging information.  */
  if (find_pc_partial_function (start_pc, NULL, &func_start, &func_end))
    {
      sal = find_pc_line (func_start, 0);

      if (sal.end < func_end
	  && start_pc <= sal.end)
	return sal.end;
    }

  return sparc_analyze_prologue (start_pc, 0xffffffffUL, &cache);
}

Mark

Re: [RFC] Is skip_prologue_using_sal actually usable?

[Daniel Jacobowitz]

On Tue, Nov 09, 2004 at 09:50:27AM -0500, Andrew Cagney wrote:
> Mark,
> 
> DWARF 2 provides us with the exact location[s] of a prologue end, can we 
> use that?

No compiler I know of emits it.  GCC could be fixed to.  But then which
meaning to you want GCC to give to it?  Too much, or too little?

-- 
Daniel Jacobowitz