Re: frame theory, was pointer madness

NZG
2006-01-26T21:54:11Z

> > 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
Is this with respect the to legend above(prev->frame->next)?
Bacause that would imply that the ->next frame after 0 is 1, but it's not,
it's -1 correct?

prev decrements the level next increments it.

It's far easier for me to imply next with ->
and previous with <-
This seems more natural.

> 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.
And from cached values of it's read registers. In my case I suspect the
problem is that the regcache is being shown as initialized when it in fact is
not. It does not read the registers on every access.

> 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.
In my case it goes into an infinite loop and continually prints rubbish frames
to the screen.

> 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.
Well that depends on what you mean by "generic".
This is being applied to remotely debug a Coldfire core which I suspect has
some differences from your machine.
If it only works on your machine and not mine, then it has failed to be
"generic".

Also note that this is a very specific crash that only happens when you try to
unwind the frames after connecting to a remote target before beginning
execution. Have you attempted to do that?

NZG