From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10679 invoked by alias); 26 Jan 2006 21:21:58 -0000 Received: (qmail 10668 invoked by uid 22791); 26 Jan 2006 21:21:56 -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 21:21:55 +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 k0QLLGov026413; Thu, 26 Jan 2006 22:21:16 +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 k0QLLGcL010035; Thu, 26 Jan 2006 22:21:16 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k0QLLGfw017308; Thu, 26 Jan 2006 22:21:16 +0100 (CET) Date: Thu, 26 Jan 2006 21:21:00 -0000 Message-Id: <200601262121.k0QLLGfw017308@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: ngustavson@emacinc.com CC: gdb-patches@sourceware.org In-reply-to: <200601261354.12256.ngustavson@emacinc.com> (message from NZG on Thu, 26 Jan 2006 13:54:12 -0600) Subject: Re: frame theory, was pointer madness References: <200601231438.26040.ngustavson@emacinc.com> <200601261017.41108.ngustavson@emacinc.com> <20060126164315.GA7821@nevyn.them.org> <200601261354.12256.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/msg00432.txt.bz2 > From: NZG > Date: Thu, 26 Jan 2006 13:54:12 -0600 > > Lets see if I have this right. > Assuming a linked list with 5 frames, they should look like this > > level description > -1 sentinal frame(virtual) > 0 youngest frame (the deepest function call and current frame) > 1 older > 2 even older > 3 oldest > > And the list should look like this > > 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 > I think, and I have yet to successfully verify this, that the highest level > frame should have an id of zero, or at least should. > > Normal gdb appears to work by caching the frame of the highest level > to a NULL prev value, which appears to be happening somewhere when > the frame first enters existance. In the case of a gdbremote > connection this should be on connection to the remote server. When > frame 0 is the highest and lowest real level it will "unwind" frame > zero by accessing -1. which should in turn actually read the > registers from remote device. Then ->black magic - black magic -> > gdb realizes there is no higher level frame and caches a NULL there. 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. 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. 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. Mark [1] If the ISA/ABI has a "hard" frame pointer register