From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6634 invoked by alias); 15 Oct 2003 23:12:38 -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 6627 invoked from network); 15 Oct 2003 23:12:37 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 15 Oct 2003 23:12:37 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id DD4FC8003F4; Wed, 15 Oct 2003 19:12:36 -0400 (EDT) Message-ID: <3F8DD464.6050201@redhat.com> Date: Wed, 15 Oct 2003 23:12: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> In-Reply-To: <3F8DB78A.4090409@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00526.txt.bz2 Andrew Cagney wrote: >> @@ -288,6 +297,9 @@ >> eq = 0; >> else if (l.stack_addr != r.stack_addr) >> /* If .stack addresses are different, the frames are different. */ >> + eq = 0; >> + else if (l.special_addr != r.special_addr) >> + /* If .special addresses are different, the frames are >> different. */ >> eq = 0; >> else if (l.code_addr == 0 || r.code_addr == 0) >> /* A zero code addr is a wild card, always succeed. */ > > > Looking at the full code: > >> int >> frame_id_eq (struct frame_id l, struct frame_id r) >> { >> int eq; >> if (l.stack_addr == 0 || r.stack_addr == 0) >> /* Like a NaN, if either ID is invalid, the result is false. */ >> eq = 0; >> else if (l.stack_addr != r.stack_addr) >> /* If .stack addresses are different, the frames are different. */ >> eq = 0; >> 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. */ >> eq = 1; >> else >> /* No luck. */ >> eq = 0; >> if (frame_debug) >> { >> fprintf_unfiltered (gdb_stdlog, "{ frame_id_eq (l="); >> fprint_frame_id (gdb_stdlog, l); >> fprintf_unfiltered (gdb_stdlog, ",r="); >> fprint_frame_id (gdb_stdlog, r); >> fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", eq); >> } >> return eq; >> } > > > Is there a need to allow wild card SPECIAL_ADDRs here? The user can > specify: > (gdb) frame > and on some architectures: > (gdb) frame > and have GDB jump to that frame. It relies on the wild-card mechanism > to give approx matches (otherwize the user will have to fully specify > , and ). > Hmm, good point. I see arguments for either choice. IMO, it would be best to make it easier for the user for the most common case. The most common case will use the stack so the stack addr is enough to distinguish the frame. If a false match is made, the end-user still has the option to specify more information. I will change this. > Looking at: > >> 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. -- Jeff J.