From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22820 invoked by alias); 25 Jan 2006 04:41:07 -0000 Received: (qmail 22812 invoked by uid 22791); 25 Jan 2006 04:41:06 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jan 2006 04:41:04 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HRG27497; Wed, 25 Jan 2006 06:39:49 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-84-228-248-224.inter.net.il [84.228.248.224]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CNX43250 (AUTH halo1); Wed, 25 Jan 2006 06:39:45 +0200 (IST) Date: Wed, 25 Jan 2006 04:41:00 -0000 Message-Id: From: Eli Zaretskii To: Jim Blandy CC: ngustavson@emacinc.com, gdb-patches@sourceware.org In-reply-to: <8f2776cb0601241600g4fd54578w10e8f1000b044e26@mail.gmail.com> (message from Jim Blandy on Tue, 24 Jan 2006 16:00:55 -0800) Subject: Re: gdb code review, pointer madness Reply-to: Eli Zaretskii References: <200601231438.26040.ngustavson@emacinc.com> <200601241328.33774.ngustavson@emacinc.com> <8f2776cb0601241327t4b9e4820l532d1133484879bb@mail.gmail.com> <200601241557.10320.ngustavson@emacinc.com> <8f2776cb0601241600g4fd54578w10e8f1000b044e26@mail.gmail.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/msg00397.txt.bz2 > Date: Tue, 24 Jan 2006 16:00:55 -0800 > From: Jim Blandy > Cc: gdb-patches@sourceware.org > > 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. Ah! wouldn't it be swell if this description finds its way to gdbint.texinfo?