From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80702 invoked by alias); 18 Apr 2016 15:55:07 -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 80678 invoked by uid 89); 18 Apr 2016 15:55:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1371, coin X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 18 Apr 2016 15:55:05 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3AD5763142; Mon, 18 Apr 2016 15:55:04 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3IFt2eq015659; Mon, 18 Apr 2016 11:55:03 -0400 Subject: Re: [PATCH 2/2] Involve gdbarch in taking DWARF register pieces To: Andreas Arnez References: <20160415180943.4FEE857EE@oc7340732750.ibm.com> <571134CD.8080507@redhat.com> <5714E6EA.8050905@redhat.com> Cc: Ulrich Weigand , gdb-patches@sourceware.org, Ulrich Weigand From: Pedro Alves Message-ID: <57150356.3090508@redhat.com> Date: Mon, 18 Apr 2016 15:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00412.txt.bz2 On 04/18/2016 04:02 PM, Andreas Arnez wrote: > On Mon, Apr 18 2016, Pedro Alves wrote: > OK. Now, reading this again, it seems to me that I should better add > the following disclaimer at the end: > > ... This method also applies when interpreting a register as a > LEN-sized type, except when convert_register_p indicates that a > special conversion is required instead. > > Still OK? Hmm, isn't "type" the other side of the same coin though? How about this: Determine the physical placement of a type of size LEN within register *REGNUM, possibly overwriting *REGNUM. (E.g., some ABIs lay vector types in registers pairs, and thus this method writes the correct pair element to *REGNUM). Returns the byte offset of the data within the (possibly adjusted) register. This method is used when determining the placement of a DWARF piece (DW_OP_piece), or when interpreting a register as a LEN-sized type, except when convert_register_p indicates that a special conversion is required instead. >> I'd suggest even calling it "dwarf_register_piece_placement" for >> caller clarity? > > Sure, but I find a name like 'gdbarch_dwarf_register_piece_placement' a > bit too unwieldy when trying to stick to an 80 char line size limit. > Maybe 'gdbarch_register_piece_placement'? Deal. :-) Thanks, Pedro Alves