Re: [RFA] Artifical dwarf2 debug info

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Dec 16, 2002 at 02:25:15PM -0500, Andrew Cagney wrote:
> 
> >>
> >>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.
> >
> >
> >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?

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer