Re: [RFC] Is skip_prologue_using_sal actually usable?

[Mark Kettenis <kettenis at gnu dot org>]

   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