From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24825 invoked by alias); 26 Jan 2006 21:54:11 -0000 Received: (qmail 24816 invoked by uid 22791); 26 Jan 2006 21:54:10 -0000 X-Spam-Check-By: sourceware.org Received: from mail.emacinc.com (HELO mail.emacinc.com) (208.248.202.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jan 2006 21:54:06 +0000 Received: from emac77.emacinc.com ([208.248.202.77] helo=eng011.emacinc.com) by mail.emacinc.com with esmtp (Exim 4.50) id 1F2F3v-0007Tn-1J; Thu, 26 Jan 2006 15:53:52 -0600 From: NZG To: Mark Kettenis Date: Thu, 26 Jan 2006 21:54:00 -0000 User-Agent: KMail/1.8.2 References: <200601231438.26040.ngustavson@emacinc.com> <200601261354.12256.ngustavson@emacinc.com> <200601262121.k0QLLGfw017308@elgar.sibelius.xs4all.nl> In-Reply-To: <200601262121.k0QLLGfw017308@elgar.sibelius.xs4all.nl> Cc: gdb-patches@sourceware.org MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200601261552.46222.ngustavson@emacinc.com> X-SA-Exim-Connect-IP: 208.248.202.77 X-SA-Exim-Mail-From: ngustavson@emacinc.com Subject: Re: frame theory, was pointer madness Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Relay: X-IsSubscribed: yes 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/msg00433.txt.bz2 > > 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