Re: [RFA] Artifical dwarf2 debug info

[Daniel Jacobowitz <drow@mvista.com>]

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

OK, I follow you now.  Hmm...

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

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.

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer