From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20402 invoked by alias); 17 Oct 2003 16:32:39 -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 20393 invoked from network); 17 Oct 2003 16:32:38 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 17 Oct 2003 16:32:38 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 33FC98003F7; Fri, 17 Oct 2003 12:32:38 -0400 (EDT) Message-ID: <3F9019A6.30109@redhat.com> Date: Fri, 17 Oct 2003 16:32:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Cagney 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> <3F8FEF0B.7000104@redhat.com> In-Reply-To: <3F8FEF0B.7000104@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00588.txt.bz2 Patch checked into mainline. Thanks. -- Jeff J. Andrew Cagney wrote: > >> 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) >> { > > > >