Re: gdb code review, pointer madness

[Jim Blandy <jimb at red-bean dot com>]

On 1/24/06, NZG <ngustavson@emacinc.com> wrote:
> If I'm asking the wrong list please point me the right direction, this seemed
> the closest to a developer list out of the choices.

I think this is the right place.

> I think I'm getting ahead of myself and assuming too much.
> I've bitten off a lot with this project and have a lot to learn yet.

Hah!  You have only just begun to suffer!  :)

> First off, I think I'm getting confused between the innermost frame and the
> sentinal frame, which I was originally assuming were one and the same.

GDB's current frame model is the result of an incremental cleanup of
working code, not a fresh design, so it's a little weird.

The natural model would be to have a frame object, with methods that
read and write that frame's registers.  Reading and writing the
youngest frame's registers would simply read and write the processor's
current registers.  Older frames may have some registers saved on the
stack by younger frames, so accessing the older frames' registers
would do a mix of memory accesses and register accesses, as
appropriate.

GDB's model is that you "unwind" a frame's registers from the next
younger frame.  That is, to access the registers of frame #1 (the
next-to-youngest frame), you actually apply frame_unwind_register to
frame #0 (the youngest frame).  Okay, whatever.  But then the obvious
question is: how do you access the registers of the youngest frame
itself?  How do you 'unwind' them when they're not wound up?

Thus the sentinel frame, the "-1st" frame.

If I remember right, the 'where' command should be printing out the
frames as it discovers them.  So if you're getting a lot of memory
traffic and no actual frames being listed, you're probably getting
stuck unwinding a single frame, as Daniel says.