Frame handling
Andrew Cagney
ac131313@redhat.com
Tue Jul 1 04:18:00 GMT 2003
>> this_id - Given a frame, return a unique identifier for the caller's frame
>> based on the caller's frame base address and the calling functions entry
>> point.
>> prev_register - Given a frame, return the value of a specified register as
>> it was on entry to this function (registers that are known to be saved on
>> the stack)
>>
>> Question - what registers is gdb expecting prev_register to give reasonable
>> results for? Just PC? Or SP and FP as well?
>
>
> As many as possible. This _completely_ replaces all other unwinding,
> for instance frame_chain and the extra_info/saved_registers data.
> Might want to take a look at the ARM conversion I just posted; I don't
> promise it's right...
Yes. GDB now relies on the prev_register method when popping a frame so
unless it works well, things fail pretty quick.
>> Question - reading through this again I think the goal of call these
>> functions is to work with the current frame and the function get passed the
>> child frame so they can do a backtrace if it hasn't already been done... why
>> not call a function to do a 1 level backtrace and then eliminate the
>> next_frame parameter? It would recduce confusion and most ports will have an
>> internal unwind function anyway.
> Because it doesn't make much difference, I think. The key is that the
> info generated when doing the backtrace is target specific, and opaque.
I'm not sure I understand the question.
Andrew
More information about the Gdb
mailing list