Re: frame theory, was pointer madness

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: NZG <ngustavson@emacinc.com>
> Date: Thu, 26 Jan 2006 15:52:46 -0600
> 
> > > 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)?

No it isn't.

> 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.

Sure, but that's a pretty meaningless way of thinking about frames.
You can only unwind (i.e. go in the prev direction).

> > 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.

Sure but that's irrelevant for understanding how GDB uses frames.
(It may be relevant to bugs in your configuration though).

> > 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.

As long as the frame number for each frame is different, that's not
totally unexpected.  If you're stack is thrashed (or if you don't have
a valid stack at all), you can't expect gdb to produce a valid
backtrace.

> > 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".

Heh.  Well, I guess the code basically assumes it's using an ancient
Unix on an origional m68k cpu.

> This is being applied to remotely debug a Coldfire core which I suspect has 
> some differences from your machine.

Dunno, but if the Coldfire still has the same basic instruction set as
the origional m68k and uses the same registers as %fp and %sp, the
unwind code should be ok.

> 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?

I'm talking about a native OpenBSD/m68k GDB, so there os no remote
target to connect to.

To me, it looks like you're connecting to a buggy stub.

Mark