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