From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20657 invoked by alias); 26 Jan 2006 22:40:47 -0000 Received: (qmail 20639 invoked by uid 22791); 26 Jan 2006 22:40:46 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jan 2006 22:40:43 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k0QMe7dN007748; Thu, 26 Jan 2006 23:40:07 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k0QMe7Lw028641; Thu, 26 Jan 2006 23:40:07 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k0QMe7SC026344; Thu, 26 Jan 2006 23:40:07 +0100 (CET) Date: Thu, 26 Jan 2006 22:40:00 -0000 Message-Id: <200601262240.k0QMe7SC026344@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: ngustavson@emacinc.com CC: mark.kettenis@xs4all.nl, gdb-patches@sourceware.org In-reply-to: <200601261552.46222.ngustavson@emacinc.com> (message from NZG on Thu, 26 Jan 2006 15:52:46 -0600) Subject: Re: frame theory, was pointer madness References: <200601231438.26040.ngustavson@emacinc.com> <200601261354.12256.ngustavson@emacinc.com> <200601262121.k0QLLGfw017308@elgar.sibelius.xs4all.nl> <200601261552.46222.ngustavson@emacinc.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00434.txt.bz2 > From: NZG > 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