From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1245 invoked by alias); 24 Mar 2011 15:54:50 -0000 Received: (qmail 1237 invoked by uid 22791); 24 Mar 2011 15:54:49 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate4.uk.ibm.com (HELO mtagate4.uk.ibm.com) (194.196.100.164) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Mar 2011 15:54:45 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate4.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p2OFsbxV014786 for ; Thu, 24 Mar 2011 15:54:37 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2OFt5CC1843220 for ; Thu, 24 Mar 2011 15:55:05 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p2OFsa4w022829 for ; Thu, 24 Mar 2011 09:54:36 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p2OFsZew022704; Thu, 24 Mar 2011 09:54:35 -0600 Message-Id: <201103241554.p2OFsZew022704@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 24 Mar 2011 16:54:35 +0100 Subject: Re: New ARI warning Sat Mar 19 01:54:11 UTC 2011 To: pedro@codesourcery.com (Pedro Alves) Date: Thu, 24 Mar 2011 18:32:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, brobecker@adacore.com (Joel Brobecker) In-Reply-To: <201103231742.17098.pedro@codesourcery.com> from "Pedro Alves" at Mar 23, 2011 05:42:16 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg01077.txt.bz2 Pedro Alves wrote: > On Wednesday 23 March 2011 17:16:01, Joel Brobecker wrote: > > > This was a large diff, but in fact, there is only one new warning: > > > > > > > gdb/i386-tdep.c:1693: obsolete: frame_register_read: Replace frame_register_read() with get_frame_register(), or possibly introduce a new method safe_get_frame_register() > > > gdb/i386-tdep.c:1693: && frame_register_read (this_frame, cache->saved_sp_reg, buf)) > > > > I just had a look at this ARI warning. The comment on > > frame_register_read says: > > > > /* FIXME: cagney/2003-02-02: Should be deprecated or replaced with a > > function called get_frame_register_p(). This slightly weird (and > > older) variant of get_frame_register() returns zero (indicating the > > register value is unavailable/invalid) if either: the register > > isn't cached; or the register has been optimized out; or the > > register contents are unavailable (because they haven't been > > collected in a traceframe). Problem is, neither check is exactly > > correct. A register can't be optimized out (it may not have been > > saved as part of a function call); The fact that a register isn't > > in the register cache doesn't mean that the register isn't > > available (it could have been fetched from memory). */ > > > > I have had this feeling that we have way too many ways to read/write > > frame registers, but I'm wondering if this comment might not be > > too zealous in this case. This function seems useful, because it > > returns a status as opposed to get_frame_register, which has the exact > > same profile except that it throws instead of returning. So I'm thinking > > we should remove the "deprecation" fixme, and just keep the FIXME for > > fixing whatever incorrectness might be left, and then remove this from > > the ARI. > > > > Thoughts? > > Agreed. I think that all users that require this additional status information should just use the (new) get_frame_register_value, and look at that value's properties. So I do think that frame_register_read ought to stay deprecated; we need to remove those extraneous frame register routines ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com