From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 503 invoked by alias); 16 Oct 2003 21:49:04 -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 496 invoked from network); 16 Oct 2003 21:49:03 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 16 Oct 2003 21:49:03 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 9E5408003F4; Thu, 16 Oct 2003 17:49:03 -0400 (EDT) Message-ID: <3F8F124F.5080509@redhat.com> Date: Thu, 16 Oct 2003 21:49: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> In-Reply-To: <3F8F0850.7080104@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00566.txt.bz2 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 :-) > > Andrew > > > >