From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3221 invoked by alias); 17 Oct 2003 13:30:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3087 invoked from network); 17 Oct 2003 13:30:52 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 17 Oct 2003 13:30:52 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4CB6C2B89; Fri, 17 Oct 2003 09:30:51 -0400 (EDT) Message-ID: <3F8FEF0B.7000104@redhat.com> Date: Fri, 17 Oct 2003 13:30:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "J. Johnston" Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: frame id enhancement References: <3F81DB50.6020202@redhat.com> <3F8DB78A.4090409@redhat.com> <3F8DD464.6050201@redhat.com> <3F8EC2B3.5040100@redhat.com> <3F8EEC26.60101@redhat.com> <3F8F0850.7080104@redhat.com> <3F8F124F.5080509@redhat.com> <3F8F2A96.1070708@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00585.txt.bz2 > Is the revised attached patch ok? Yep, now I understand it. Thanks. Andrew ex: frame.h > =================================================================== > RCS file: /cvs/src/src/gdb/frame.h,v > retrieving revision 1.110 > diff -u -r1.110 frame.h > --- frame.h 10 Oct 2003 00:32:04 -0000 1.110 > +++ frame.h 16 Oct 2003 23:30:50 -0000 > @@ -95,8 +95,6 @@ > is used. Watch out for all the legacy targets that still use the > function pointer register or stack pointer register. They are > wrong. */ > - /* NOTE: cagney/2002-11-16: The ia64 has two stacks and hence two > - frame bases. This will need to be expanded to accomodate that. */ > CORE_ADDR stack_addr; > /* The frame's code address. This shall be constant through out the > lifetime of the frame. While the PC (a.k.a. resume address) > @@ -104,15 +102,33 @@ > Typically, it is set to the address of the entry point of the > frame's function (as returned by frame_func_unwind(). */ > CORE_ADDR code_addr; > + /* The frame's special address. This shall be constant through out the > + lifetime of the frame. This is used for architectures that may have > + frames that do not change the stack but are still distinct and have > + some form of distinct identifier (e.g. the ia64 which uses a 2nd > + stack for registers). This field is treated as unordered - i.e. will > + not be used in frame ordering comparisons such as frame_id_inner(). > + A zero in this field will be treated as a wild-card when comparing > + frames for equality. */ > + CORE_ADDR special_addr; > }; > > /* Methods for constructing and comparing Frame IDs. > > - NOTE: Given frameless functions A and B, where A calls B (and hence > + NOTE: Given stackless functions A and B, where A calls B (and hence > B is inner-to A). The relationships: !eq(A,B); !eq(B,A); > - !inner(A,B); !inner(B,A); all hold. This is because, while B is > - inner to A, B is not strictly inner to A (being frameless, they > - have the same .base value). */ > + !inner(A,B); !inner(B,A); all hold. > + > + This is because, while B is inner-to A, B is not strictly inner-to A. > + Being stackless, they have an identical .stack_addr value, and differ > + only by their unordered .code_addr and/or .special_addr values. > + > + Because frame_id_inner is only used as a safety net (e.g., > + detect a corrupt stack) the lack of strictness is not a problem. > + Code needing to determine an exact relationship between two frames > + must instead use frame_id_eq and frame_id_unwind. For instance, > + in the above, to determine that A stepped-into B, the equation > + "A.id != B.id && A.id == id_unwind (B)" can be used. */ > > /* For convenience. All fields are zero. */ > extern const struct frame_id null_frame_id; > @@ -120,9 +136,20 @@ > /* Construct a frame ID. The first parameter is the frame's constant > stack address (typically the outer-bound), and the second the > frame's constant code address (typically the entry point) (or zero, > - to indicate a wild card). */ > + to indicate a wild card). The special identifier address is > + defaulted to zero. */ > extern struct frame_id frame_id_build (CORE_ADDR stack_addr, > CORE_ADDR code_addr); > + > +/* Construct a special frame ID. The first parameter is the frame's constant > + stack address (typically the outer-bound), the second is the > + frame's constant code address (typically the entry point) (or zero, > + to indicate a wild card), and the third parameter is the frame's > + special identifier address (or zero to indicate a wild card or > + unused default). */ > +extern struct frame_id frame_id_build_special (CORE_ADDR stack_addr, > + CORE_ADDR code_addr, > + CORE_ADDR special_addr); > > /* Returns non-zero when L is a valid frame (a valid frame has a > non-zero .base). */ > Index: frame.c > =================================================================== > RCS file: /cvs/src/src/gdb/frame.c,v > retrieving revision 1.145 > diff -u -r1.145 frame.c > --- frame.c 2 Oct 2003 20:28:29 -0000 1.145 > +++ frame.c 16 Oct 2003 23:30:51 -0000 > @@ -144,9 +144,10 @@ > void > fprint_frame_id (struct ui_file *file, struct frame_id id) > { > - fprintf_unfiltered (file, "{stack=0x%s,code=0x%s}", > + fprintf_unfiltered (file, "{stack=0x%s,code=0x%s,special=0x%s}", > paddr_nz (id.stack_addr), > - paddr_nz (id.code_addr)); > + paddr_nz (id.code_addr), > + paddr_nz (id.special_addr)); > } > > static void > @@ -256,14 +257,22 @@ > const struct frame_id null_frame_id; /* All zeros. */ > > struct frame_id > -frame_id_build (CORE_ADDR stack_addr, CORE_ADDR code_addr) > +frame_id_build_special (CORE_ADDR stack_addr, CORE_ADDR code_addr, > + CORE_ADDR special_addr) > { > struct frame_id id; > id.stack_addr = stack_addr; > id.code_addr = code_addr; > + id.special_addr = special_addr; > return id; > } > > +struct frame_id > +frame_id_build (CORE_ADDR stack_addr, CORE_ADDR code_addr) > +{ > + return frame_id_build_special (stack_addr, code_addr, 0); > +} > + > int > frame_id_p (struct frame_id l) > { > @@ -292,8 +301,14 @@ > else if (l.code_addr == 0 || r.code_addr == 0) > /* A zero code addr is a wild card, always succeed. */ > eq = 1; > - else if (l.code_addr == r.code_addr) > - /* The .stack and .code are identical, the ID's are identical. */ > + else if (l.code_addr != r.code_addr) > + /* If .code addresses are different, the frames are different. */ > + eq = 0; > + else if (l.special_addr == 0 || r.special_addr == 0) > + /* A zero special addr is a wild card (or unused), always succeed. */ > + eq = 1; > + else if (l.special_addr == r.special_addr) > + /* Frames are equal. */ > eq = 1; > else > /* No luck. */ > @@ -320,7 +335,7 @@ > /* Only return non-zero when strictly inner than. Note that, per > comment in "frame.h", there is some fuzz here. Frameless > functions are not strictly inner than (same .stack but > - different .code). */ > + different .code and/or .special address). */ > inner = INNER_THAN (l.stack_addr, r.stack_addr); > if (frame_debug) > {