From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12610 invoked by alias); 23 Nov 2016 09:26:41 -0000 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 Received: (qmail 12592 invoked by uid 89); 23 Nov 2016 09:26:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:Wed, 15pm, solely, letter X-HELO: mail-wj0-f174.google.com Received: from mail-wj0-f174.google.com (HELO mail-wj0-f174.google.com) (209.85.210.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Nov 2016 09:26:38 +0000 Received: by mail-wj0-f174.google.com with SMTP id qp4so5710482wjc.3 for ; Wed, 23 Nov 2016 01:26:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=w3l5Ym541pvuwML9/6SKkkW70PlV/JFWNgp0ub7fEec=; b=XnKcs0r3lZWx7Ceaf3Cswl5MRddHbb49TdlQOOMFuCfi2P9bEJYGh0qu/y0vrMWR87 KF8NAAthSrdqry+pI4iDU6E3DFYkbF4i4s7zYh7DZwetUGtPlOgUUDR30ecLpPgE0PLw SeidueDbqooIodY+xzc2f8qRr2A6Liu0nz2pHjk0niuvNRr/5mSSpJXHcdQXkfFyftG2 Cbx7LFAgcW7dLhpDsFASjrNgcXTv/Wj5WOA59xKjzxpleX2Byv6QfIMdyMfsjADKNHBt w0rZLulbZvaIEuFxhiDOvjtef9bzBHgGFI3uJjpk1+DdmkXRfUh0K+44kpsG6nn2IWYQ MtJg== X-Gm-Message-State: AKaTC01xV7z0epHzTQB202z9Ai1EwNEfaNocC3l+v+AUmyqc6C30OfYivrq2I9z6aZ+/nw== X-Received: by 10.194.113.129 with SMTP id iy1mr2325702wjb.127.1479893196074; Wed, 23 Nov 2016 01:26:36 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id ba10sm35261916wjb.32.2016.11.23.01.26.33 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 23 Nov 2016 01:26:35 -0800 (PST) Date: Wed, 23 Nov 2016 09:26:00 -0000 From: Yao Qi To: Ulrich Weigand Cc: Pedro Alves , Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] New function value_has_address Message-ID: <20161123092621.GD24810@E107787-LIN> References: <20161122181616.118F810B923@oc8523832656.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161122181616.118F810B923@oc8523832656.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00663.txt.bz2 On Tue, Nov 22, 2016 at 07:16:15PM +0100, Ulrich Weigand wrote: > > I think that it's good that the names match. If one is renamed, > > so should the other, IMO. Maybe call the function > > value_has_address_location? I think it'd be good if the > > function's intro comment made this link more explicit. > > Actually, I see now that patch #3 tweaks the comment. > > I think part of the confusion is that the comment above is simply > no longer true; for lval_register values, address is *not* (any longer) > used to hold any byte offset into a register structure, as far as I > can see. Instead, for lval_register values, the register that holds > the value is identifed solely via the VALUE_REGNUM/VALUE_NEXT_FRAME_ID > fields, and the address field is ignored. That is what I am saying in the last paragraph of cover letter. > > I think we should reword the comments to reflect the fact that > "address" is only used for lval_address. On the other hand, > the regnum/frame_id fields should move into the union and only > be used for lval_register values ... > That is what I am trying to do in next step. Let me finish it and include it in this series as well. -- Yao (齐尧)