Re: [RFA] Artifical dwarf2 debug info

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Dec 16, 2002 at 01:00:57PM -0500, Andrew Cagney wrote:
> 
> >That's right.
> >
> >
> >>If that is the case then I don't think this is either necessary or 
> >>correct.  A `struct frame_info' allows frame specific unwind functions - 
> >>at present only dummy-frame and saved-regs-frame versions are 
> >>implemented, however the next ones to implement are cfi-frame (unwind 
> >>using CFI info) and regs-frame (unwind using the register cache).
> >>
> >>For your problem, wouldn't it be better to, instead of creating fake CFI 
> >>info, implement custom frame unwind functions that handle your case?
> >
> >
> >Hrm.  What do you mean by regs-frame?  If it's for the current frame
> >wouldn't that be a frame which just doesn't unwind?
> 
> 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.

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.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer