From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31841 invoked by alias); 25 Jan 2006 18:49:28 -0000 Received: (qmail 31832 invoked by uid 22791); 25 Jan 2006 18:49:28 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.203) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jan 2006 18:49:26 +0000 Received: by zproxy.gmail.com with SMTP id x3so207676nzd for ; Wed, 25 Jan 2006 10:49:25 -0800 (PST) Received: by 10.36.8.15 with SMTP id 15mr780131nzh; Wed, 25 Jan 2006 10:49:25 -0800 (PST) Received: by 10.37.2.5 with HTTP; Wed, 25 Jan 2006 10:49:25 -0800 (PST) Message-ID: <8f2776cb0601251049h742c3a20rf7f5f3f062888a1c@mail.gmail.com> Date: Wed, 25 Jan 2006 18:49:00 -0000 From: Jim Blandy To: Eli Zaretskii Subject: Re: gdb code review, pointer madness Cc: ngustavson@emacinc.com, gdb-patches@sourceware.org In-Reply-To: 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> <8f2776cb0601241600g4fd54578w10e8f1000b044e26@mail.gmail.com> <8f2776cb0601242059k7035c590mffd81ad95c2ffe9c@mail.gmail.com> <8f2776cb0601242125v6ef329c0j58f6ac185423ace9@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/msg00415.txt.bz2 On 1/25/06, Eli Zaretskii wrote: > > Date: Tue, 24 Jan 2006 21:25:44 -0800 > > From: Jim Blandy > > Cc: ngustavson@emacinc.com, gdb-patches@sourceware.org > > > > I'm being lazy. How's this? > > Almost perfect. If you add a "@cindex sentinel frame" and a > "@findex frame_register_unwind", it will be _just_ perfect. > > Actually, maybe also "@cindex frame, unwind". I've committed the below, adding @vindex SENTINEL_FRAME: gdb/doc/ChangeLog: 2006-01-24 Jim Blandy * gdbint.texinfo (Frames): Document the basics of GDB's register unwinding model, and explain the existence of the "sentinel" frame. Index: gdb/doc/gdbint.texinfo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v retrieving revision 1.235 diff -c -p -r1.235 gdbint.texinfo *** gdb/doc/gdbint.texinfo 20 Jan 2006 21:58:16 -0000 1.235 --- gdb/doc/gdbint.texinfo 25 Jan 2006 18:45:33 -0000 *************** they use. *** 231,236 **** --- 231,266 ---- A frame is a construct that @value{GDBN} uses to keep track of calling and called functions. + @cindex frame, unwind + @value{GDBN}'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 have a frame object, with methods that read + and write that frame's registers. Reading or writing the youngest + frame's registers would simply read or write the processor's current + registers, since the youngest frame is running directly on the + processor. Older frames might 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. + + @findex frame_register_unwind + Instead, @value{GDBN}'s model is that you find a frame's registers by + ``unwinding'' them from the next younger frame. That is, to access + the registers of frame #1 (the next-to-youngest frame), you actually + apply @code{frame_register_unwind} to frame #0 (the youngest frame). + 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? + + @cindex sentinel frame + @findex get_frame_type + @vindex SENTINEL_FRAME + To answer this question, GDB has the @dfn{sentinel} frame, the + ``-1st'' frame. Unwinding registers from the sentinel frame gives you + the current values of the youngest real frame's registers. If @var{f} + is a sentinel frame, then @code{get_frame_type (@var{f}) =3D=3D + SENTINEL_FRAME}. + @findex create_new_frame @vindex FRAME_FP @code{FRAME_FP} in the machine description has no meaning to the