From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3027 invoked by alias); 27 May 2014 11:54:09 -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 2995 invoked by uid 89); 27 May 2014 11:54:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp11.uk.ibm.com Received: from e06smtp11.uk.ibm.com (HELO e06smtp11.uk.ibm.com) (195.75.94.107) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 27 May 2014 11:54:05 +0000 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 May 2014 12:54:02 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 27 May 2014 12:54:00 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 1CC632190042 for ; Tue, 27 May 2014 12:53:50 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps3075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s4RBrxaB1048878 for ; Tue, 27 May 2014 11:53:59 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s4RBrxXw009120 for ; Tue, 27 May 2014 05:53:59 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-188.boeblingen.de.ibm.com [9.152.212.188]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s4RBrxmB009094; Tue, 27 May 2014 05:53:59 -0600 From: Andreas Arnez To: Yao Qi Cc: Subject: Re: [PATCH 01/12] regcache: Add functions suitable for regset_supply/collect. References: <1401122208-2481-1-git-send-email-arnez@linux.vnet.ibm.com> <1401122208-2481-2-git-send-email-arnez@linux.vnet.ibm.com> <5383FC9B.4040400@codesourcery.com> Date: Tue, 27 May 2014 11:54:00 -0000 In-Reply-To: <5383FC9B.4040400@codesourcery.com> (Yao Qi's message of "Tue, 27 May 2014 10:46:51 +0800") Message-ID: <877g5777zd.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14052711-5024-0000-0000-000000240AD2 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00661.txt.bz2 On Tue, May 27 2014, Yao Qi wrote: > On 05/27/2014 12:36 AM, Andreas Arnez wrote: >> +/* Mapping between register numbers and offsets in a buffer, for use >> + in the '*regset' functions below. The first entry in a map refers >> + to offset 0, and each entry increases the offset by its size. > > Except that 'regno' is REGCACHE_MAP_SKIP_BYTES. When 'regno' is > REGCACHE_MAP_SKIP_BYTES, 'count' is the increased offset by bytes, IIUC. Correct. Maybe it's better to rephrase the whole comment like this: /* Mapping between register numbers and offsets in a buffer, for use in the '*regset' functions below. In an array of 'regcache_map_entry' each element is interpreted like follows: - If 'regno' is a register number: Map register 'regno' to the current offset (starting with 0) and increase the current offset by the register's size. Repeat this with consecutive register numbers up to 'regno+count-1'. - If 'regno' has the special value REGCACHE_MAP_SKIP_BYTES: Add 'count' to the current offset. - If count=0: End of the map. */ > >> +/* Transfer a set of registers (as described by REGSET) between >> + REGCACHE and BUF. If REGNUM == -1, transfer all registers >> + belonging to the regset, otherwise just the register numbered >> + REGNUM. The REGSET's 'descr' field must point to an array of >> + 'struct regcache_map_entry'. > > IWBN to update the comments to 'descr' field, and go a step further, > rename field 'descr'. With the new name being something like 'map' or 'regmap', I guess? If that's what you mean, I tend to agree, and I could provide a separate patch for that. >> + >> + These functions are suitable for the 'regset_supply' and >> + 'regset_collect' fields in a regset structure. >> + */ > > "*/" should go to the previous line. Done.