Re: [RFA] Artifical dwarf2 debug info

[Andrew Cagney <ac131313 at redhat dot com>]

> > A frame that gets the saved registers from the register cache.  As for uses:
> > - an inner-most frame that for some reason doesn't unwind (i.e., 
> > create_new_frame() barfs).
> > - the frame that is inner to `current frame'.
>
> I'm confused again :)
>
> "Current frame" is one which does not unwind, right?  No saved PC, no
> saved registers.  The concepts are meaningless.  Its frame ID
> corresponds (very) loosely to the current stack pointer.  This would be
> frame #0 in a backtrace.  There's nothing inside of it.
The, in theory, operation:
  frame_register_unwind (get_next_frame (get_current_frame()), ...)
however, they wouldn't be implemented that way.  I'm sitting on patch 
that shows this working.

The operation:
  frame_id_unwind (get_next_frame (current_frame), ...)
  frame_pc_unwind (get_next_frame (current_frame), ...)
are, unfortunatly, more complicated.  At their core is 
DECR_PC_AFTER_BREAK (and why I've not posted that patch).

> Or are you saying that the innermost frame is this special regs-frame,
> and the current frame (still #0) is outside of that?  OK, that jives
> with some things I remember you describing earlier.  Makes sense now.
>
> I don't see what you mean by "doesn't unwind", since we always start
> with having the current frame (i.e. there would be at least two) but I
> think I'm back on your page again.
INIT_FRAME_EXTRA_INFO() can throw an error.  For instance, due to an 
attempt to read from an address specified by PC/FP/SP when that address 
is invalid.  For such cases, there should still be a current frame (so 
that `info registers' works) but it shouldn't unwind any further.

So again, yes, you'll end up with current-frame -> regs-frame.

> > >As for this situation, and the similar one for i386... there are three
> > >unwind functions, to find the previous frame's registers, ID, and PC.
> > >For this case we just want to express a normal function call which
> > >saves no registers; pretty easy.  But for i386 I'll want to express
> > >something which initially pushes a register, and then does some work,
> > >pops it, and does more work before returning.
> > So you're proposing that the saved-regs code be used to generate a cfi 
> > description as well?
> >
> > Interesting.
>
> Precisely.  When given a function without enough information to
> backtrace through it in the debug info, the prologue scanner could
> implement this new method in order to provide backtraces.  It could
> really clear up some messes.
>
> I think it's a promising idea.
Need to figure out how/were this should tie into the rest of the frame 
structure.  The CFI code is not exactly integrated into the mainstream.

Here, the key function is get_prev_frame() where GDB first unwinds the 
PC and then uses that to determine what is needed to unwind/create the 
rest of the frame.  It could easily read:

	if (pc in dummy-frame)
	  create dummy frame;
	else if (pc in cfi frame)
	  create cfi frame;
	else if (pc in something else)
	  create some other frame;

or even:

	while (frame in known unwind types)
	  if (frame and pc match)
	    return create that frame;

that is, a target will support a number of frame types, each identified 
using the PC.

Andrew