From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15075 invoked by alias); 25 Jan 2006 00:01:04 -0000 Received: (qmail 15065 invoked by uid 22791); 25 Jan 2006 00:01:03 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.198) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jan 2006 00:00:57 +0000 Received: by zproxy.gmail.com with SMTP id x3so1302748nzd for ; Tue, 24 Jan 2006 16:00:55 -0800 (PST) Received: by 10.36.154.20 with SMTP id b20mr62355nze; Tue, 24 Jan 2006 16:00:55 -0800 (PST) Received: by 10.37.2.42 with HTTP; Tue, 24 Jan 2006 16:00:55 -0800 (PST) Message-ID: <8f2776cb0601241600g4fd54578w10e8f1000b044e26@mail.gmail.com> Date: Wed, 25 Jan 2006 00:01:00 -0000 From: Jim Blandy To: NZG Subject: Re: gdb code review, pointer madness Cc: gdb-patches@sourceware.org In-Reply-To: <200601241557.10320.ngustavson@emacinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200601231438.26040.ngustavson@emacinc.com> <200601241328.33774.ngustavson@emacinc.com> <8f2776cb0601241327t4b9e4820l532d1133484879bb@mail.gmail.com> <200601241557.10320.ngustavson@emacinc.com> 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/msg00394.txt.bz2 On 1/24/06, NZG wrote: > If I'm asking the wrong list please point me the right direction, this se= emed > the closest to a developer list out of the choices. I think this is the right place. > I think I'm getting ahead of myself and assuming too much. > I've bitten off a lot with this project and have a lot to learn yet. Hah! You have only just begun to suffer! :) > First off, I think I'm getting confused between the innermost frame and t= he > sentinal frame, which I was originally assuming were one and the same. GDB's current frame model is the result of an incremental cleanup of working code, not a fresh design, so it's a little weird. The natural model would be to have a frame object, with methods that read and write that frame's registers. Reading and writing the youngest frame's registers would simply read and write the processor's current registers. Older frames may have some registers saved on the stack by younger frames, so accessing the older frames' registers would do a mix of memory accesses and register accesses, as appropriate. GDB's model is that you "unwind" a frame's registers from the next younger frame. That is, to access the registers of frame #1 (the next-to-youngest frame), you actually apply frame_unwind_register to frame #0 (the youngest frame). Okay, whatever. But then the obvious question is: how do you access the registers of the youngest frame itself? How do you 'unwind' them when they're not wound up? Thus the sentinel frame, the "-1st" frame. If I remember right, the 'where' command should be printing out the frames as it discovers them. So if you're getting a lot of memory traffic and no actual frames being listed, you're probably getting stuck unwinding a single frame, as Daniel says.