Re: [RFA] Artifical dwarf2 debug info

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Dec 16, 2002 at 02:56:55PM -0500, Andrew Cagney wrote:
> 
> >>>If I'm scanning this code correctly, all we would need to do would be
> >>>to connect set_unwind_by_pc to the CFI machinery.  No, it's more
> >>>complicated than that, we still call both FRAME_CHAIN and 
> >>frame_pc_unwind;
> >>>I'm not entirely clear on how frame_saved_regs_id_unwind works. 
> >>>Similarly in get_prev_frame.
> >
> >>
> >>FRAME_CHAIN is going away.
> >>
> >>The steps are broadly:
> >>	pc = pc-unwind (next_frame)
> >>	if (not an edge case like dummy frame where the id doesn't need to 
> >>	be unwound because the frame can be identified using the callee's ID)
> >>	  id = id-unwind (next_frame);
> >>	create frame from pc/id setting new unwind methods using pc.
> >>(frame_saved_regs_id_unwind is there to keep code that just implements 
> >>frame chain working.).
> >
> >
> >Great!
> >
> >
> >>>But what I'd like to see is something like you've sketched above. 
> >>>Probably check first for dummy frame, then for sigtramp frame, then for
> >>>CFI frame, and then fall back to the defaults.
> >
> >>
> >>Yes.  Should the choices/order be hardwired or specified by the 
> >>architecture though?  I.e., iterate over a list of possible frames that 
> >>are specified by the architecture.
> >
> >
> >Hmm, I'm not sure.  Do we have any architectures that would want to
> >specify their own frame types?  In such a way that using this CFI
> >approach wouldn't suffice?
> 
> Well, I'd not want to be the one enabling CFI on all architectures. 
> That code needs some serious cleanups.

Yes.  I'd like to start turning this on for other architectures, and I
suspect it'll come on for i386 when Mark K. really gets his teeth into
bringing that together with the x86-64 port.  Hopefully it will clean
up over time.

> As for own frame types, a SIGTRAMP frames are one case.

Hmm, good point, that could be handled by an architecture-dependent
list of frame types.

> >>The catch is that it needs to unwind the PC before anything else.  That 
> >>way it can correctly set the type.  Like I said, patch for that pending.
> >
> >
> >Right.  I really appreciate all your cleanups in this area.  I have
> >some work to do on FRAME_CHAIN_VALID but I'll sit on it for a while,
> >until I see what this looks like when you're done revamping the
> >unwinders.  (That's the backtrace-to-or-through-main conversation from
> >some months ago.)
> >
> >Back to the patch at the beginning of this thread - do you think this
> >view of fake CFI information is feasible?  Any comments on Michal's
> >patch?
> 
> It's feasible.  It may long term solve another problem.  Apparently GDB 
> needs to generate, at run time, debug info for things like Java.  It may 
> also be easier to handle this case by implementing direct functions and 
> not going via CFI.
> 
> That actual code, though, is a mess.  It is adding another edge case to 
> code that shouldn't have to handle anything at all.

Where's the case you're concerned about - are you refering to code in
the tdep file or in dwarf2cfi.c?

> BTW, exactly is the difference between a prologueless and frameless 
> function?  The prologue case appears to be checking for a push -> the 
> reverse of frameless.

The patch doesn't talk about frameless functions particularly - it
checks for _has_prologue, and generates an FDE based on whether it does
or not...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer