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