This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: frame theory, was pointer madness
> From: NZG <ngustavson@emacinc.com>
> Date: Thu, 26 Jan 2006 13:54:12 -0600
>
> Lets see if I have this right.
> Assuming a linked list with 5 frames, they should look like this
>
> level description
> -1 sentinal frame(virtual)
> 0 youngest frame (the deepest function call and current frame)
> 1 older
> 2 even older
> 3 oldest
>
> And the list should look like this
>
> prev->frame->next
>
> NULL->3->2->1->0->-1->-1->-1........
I get the feeling that you've got a wrong picture. I'd view things
as:
-1 -> 0 -> 1 -> 2 -> 3 -> NULL
> I think, and I have yet to successfully verify this, that the highest level
> frame should have an id of zero, or at least should.
>
> Normal gdb appears to work by caching the frame of the highest level
> to a NULL prev value, which appears to be happening somewhere when
> the frame first enters existance. In the case of a gdbremote
> connection this should be on connection to the remote server. When
> frame 0 is the highest and lowest real level it will "unwind" frame
> zero by accessing -1. which should in turn actually read the
> registers from remote device. Then ->black magic - black magic ->
> gdb realizes there is no higher level frame and caches a NULL there.
Sorry but what you say here doesn't make any sense to me. GDB unwinds
the stack from the registers values that are currently found in the
cpu. Unwinding involves interpreting debug info or analyzing code to
determine where the register values for the previous frames are
stored. This process can terminate (i.e. if we hit main, or if the
value for the frame pointer register for a frame is zero[1]) but isn't
guaranteed to. Actually the unwinding process is difficult to get
completely right, and might send us off into the wrong direction,
resulting in rubish frames.
I'm not sure what your problem is, only that GDB seems to work pretty
well on OpenBSD/mac68k, so I doubt there is a fundamental problem in
the generic m68k unwinder code.
Mark
[1] If the ISA/ABI has a "hard" frame pointer register