From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16513 invoked by alias); 16 Oct 2003 16:09:24 -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 16504 invoked from network); 16 Oct 2003 16:09:22 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 16 Oct 2003 16:09:22 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8617D2B89; Thu, 16 Oct 2003 12:09:23 -0400 (EDT) Message-ID: <3F8EC2B3.5040100@redhat.com> Date: Thu, 16 Oct 2003 16:09: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: 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00547.txt.bz2 >> int >> 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); >> if (frame_debug) >> { >> fprintf_unfiltered (gdb_stdlog, "{ frame_id_inner (l="); >> fprint_frame_id (gdb_stdlog, l); >> fprintf_unfiltered (gdb_stdlog, ",r="); >> fprint_frame_id (gdb_stdlog, r); >> fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", inner); >> } >> return inner; >> } >> >> >> does SPECIAL_ADDR add further ordering? If it doesn't then the comment needs to be updated (and the description in "frame.h" clarified). > > > Another good point. Yes, it does in this case. Two frames could both not use the stack but one will definitely move the special_addr. I need to add a SPECIAL_INNER_THAN macro which can default to false and must be overridden by the platform. Is there real value add in having SPECIAL_INNER_THAN though? It would only be called by frame_id_inner. Looking at how that method is used: > frame.c:354: if (frame_id_inner (id, this)) In frame_find_by_id: Its sole purpose is to act as a short circuit for the unlikely case where the ID isn't present in the frame. A stonger frame_id_inner has little value add. > frame.c:1909: && frame_id_inner (get_frame_id (this_frame), In get_prev_frame: Its a sainity check to detect what appears to be a badly corrupt stack. Marginal value add? > infrun.c:2094: && (frame_id_inner (get_frame_id (get_current_frame ()), Commented out. > infrun.c:2383: if (frame_id_inner (current_frame, step_frame_id)) Received a signal. Given that a predicate to the call is: && INNER_THAN (read_sp (), step_sp)) the code's assumed that a signal modifies frame_id.stack_addr, so there is no value add. It might be useful to clarify this assumption though. > infrun.c:2477: && frame_id_inner (step_frame_id, 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. Andrew