From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86655 invoked by alias); 18 Apr 2016 15:57:55 -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 86634 invoked by uid 89); 18 Apr 2016 15:57:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-vk0-f54.google.com Received: from mail-vk0-f54.google.com (HELO mail-vk0-f54.google.com) (209.85.213.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 18 Apr 2016 15:57:52 +0000 Received: by mail-vk0-f54.google.com with SMTP id c4so225448384vkb.3 for ; Mon, 18 Apr 2016 08:57:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xFO1xUU/zVNpImhd/u2a3WdxkIhdFKAS3ThH82PGKM8=; b=WZvcxHF1VNtf1apArGiIuMr0g7onNAFs9Oz3urRtmPF2X5ESX6DWFzZXGguPLmNpR3 xNA7mNnJqHdYqxryLk5EwFMj73ajAE1QJib18thnG+224ju7YB7Dp3oqP6Sca7QlsgP4 it4S4BuaCioK6x23ytcxNf3Bvn4Qevc0nvMSxWYVGq7IIZYqw55kUDmx09d3XCARcT+J oX7gRb6PJzzDiBDBYWMBgzn2v0tQuUnHON9liy1nErZaE6mFatOqaWMEnjfEDy3FjSY3 1fNS8iYTZAMlAzWbP4D/fl4QX+n2K3XACcPlVbY9MD6Mo5QiI2dkoDP1MbgZ0K1XVHsR eFyQ== X-Gm-Message-State: AOPr4FXQJpmAkeZHU4RHYbDr77z05ODnv55J5NfBFFzFdgbvzYElPvz+OE7LsxCjncLNcRLE63Uk2mHjMiVWloBD X-Received: by 10.159.37.104 with SMTP id 95mr18761103uaz.85.1460995070112; Mon, 18 Apr 2016 08:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.136.141 with HTTP; Mon, 18 Apr 2016 08:57:10 -0700 (PDT) In-Reply-To: <57150356.3090508@redhat.com> References: <20160415180943.4FEE857EE@oc7340732750.ibm.com> <571134CD.8080507@redhat.com> <5714E6EA.8050905@redhat.com> <57150356.3090508@redhat.com> From: Doug Evans Date: Mon, 18 Apr 2016 15:57:00 -0000 Message-ID: Subject: Re: [PATCH 2/2] Involve gdbarch in taking DWARF register pieces To: Pedro Alves Cc: Andreas Arnez , Ulrich Weigand , gdb-patches , Ulrich Weigand Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00414.txt.bz2 On Mon, Apr 18, 2016 at 8:55 AM, Pedro Alves wrote: > 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? This is the part that I found lacking when I read the initial patch. > 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. SGTM >>> 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 >