This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Artifical dwarf2 debug info
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