From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11504 invoked by alias); 16 Oct 2003 23:32:40 -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 11497 invoked from network); 16 Oct 2003 23:32:39 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 16 Oct 2003 23:32:39 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id CBE688003F4; Thu, 16 Oct 2003 19:32:38 -0400 (EDT) Message-ID: <3F8F2A96.1070708@redhat.com> Date: Thu, 16 Oct 2003 23: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: "J. Johnston" Cc: Andrew Cagney , 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> In-Reply-To: <3F8F124F.5080509@redhat.com> Content-Type: multipart/mixed; boundary="------------080301080507010804040308" X-SW-Source: 2003-10/txt/msg00579.txt.bz2 This is a multi-part message in MIME format. --------------080301080507010804040308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 4207 J. Johnston wrote: > Andrew Cagney wrote: > >>> >>>> It's the reverse of infrun.c:2383 where the inferior is falling out >>>> of a singnal trampoline, I think the assumptions again hold. >>>> >>>> infrun.c:2641: if (!(frame_id_inner (current_frame, step_frame_id))) >>>> >>>> "Trust me" there's no value add. While the comment reads: >>>> /* In the case where we just stepped out of a function into the >>>> middle of a line of the caller, continue stepping, but >>>> step_frame_id must be modified to current frame */ >>>> The test also updates step_frame_id when switching between frameless >>>> stackless leaf function. The extra test wouldn't fix that problem. >>>> I'll try to remember to add some comments to that code. >> >> >> >> I've done this. >> >>> Ok, that simplifies things. I have included a revised patch that >>> allows for the wild-card scenario. >> >> >> >> We're going to need more comments so that the next person better >> understands what is going on: >> >> + /* 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 have the same stack_addr and code_addr but are distinct >> + due to some other qualification (e.g. the ia64 uses a register >> + stack which is distinct from the memory stack). */ >> + CORE_ADDR special_addr; >> >> can you expand this definition to to note that the value isn't >> ordered, and that zero is treated as a wild card (its mentioned >> further down but I think here, at the definition, is better). For the >> ia64, is/can the second area be described as a register spill area >> rather than a stack? If the word "stack" can be avoided, the rationale >> for "special" being un-ordered is stronger. >> > > It "is" a register stack on the ia64. Registers r32 - r127 for any > frame all come from this area. It gets bumped up by a special alloc() > instruction. I'm not sure I would call it unordered. It may be better > to say that it is treated as unordered. That would make the comments > below much simpler - i.e. the special_addr field is treated as unordered > so it is never used to determine order when comparing frames. > > I can easily add the zero/wildcard comment. > >> For: >> >> NOTE: Given frameless 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). */ >> >> an update is needed, suggest something like: >> >> 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 stackless, they >> have an identical .stack_addr value, and differ only by their >> unordered .code_addr .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. >> >> >> and a similar update to: >> >> frame_id_inner (struct frame_id l, struct frame_id r) >> { >> int inner; >> if (l.stack_addr == 0 || r.stack_addr == 0) >> /* Like NaN, any operation involving an invalid ID always fails. */ >> inner = 0; >> else >> /* 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). */ >> inner = INNER_THAN (l.stack_addr, r.stack_addr); >> >> I can't think of a word better than "special", so I guess special it >> is :-) >> Is the revised attached patch ok? -- Jeff J. --------------080301080507010804040308 Content-Type: text/plain; name="frame_special.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="frame_special.patch" Content-length: 6014 Index: 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) { --------------080301080507010804040308--