[RFA] Artifical dwarf2 debug info
Andrew Cagney
ac131313@redhat.com
Mon Dec 16 10:56:00 GMT 2002
>> A frame that gets the saved registers from the register cache. As for uses:
>> - an inner-most frame that for some reason doesn't unwind (i.e.,
>> create_new_frame() barfs).
>> - the frame that is inner to `current frame'.
>
>
> I'm confused again :)
>
> "Current frame" is one which does not unwind, right? No saved PC, no
> saved registers. The concepts are meaningless. Its frame ID
> corresponds (very) loosely to the current stack pointer. This would be
> frame #0 in a backtrace. There's nothing inside of it.
The, in theory, operation:
frame_register_unwind (get_next_frame (get_current_frame()), ...)
however, they wouldn't be implemented that way. I'm sitting on patch
that shows this working.
The operation:
frame_id_unwind (get_next_frame (current_frame), ...)
frame_pc_unwind (get_next_frame (current_frame), ...)
are, unfortunatly, more complicated. At their core is
DECR_PC_AFTER_BREAK (and why I've not posted that patch).
> Or are you saying that the innermost frame is this special regs-frame,
> and the current frame (still #0) is outside of that? OK, that jives
> with some things I remember you describing earlier. Makes sense now.
>
> I don't see what you mean by "doesn't unwind", since we always start
> with having the current frame (i.e. there would be at least two) but I
> think I'm back on your page again.
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.
>> >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.
Andrew
More information about the Gdb-patches
mailing list