From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94794 invoked by alias); 28 Apr 2016 18:16:10 -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 94783 invoked by uid 89); 28 Apr 2016 18:16:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=representing, Hx-languages-length:1406 X-HELO: e06smtp06.uk.ibm.com Received: from e06smtp06.uk.ibm.com (HELO e06smtp06.uk.ibm.com) (195.75.94.102) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Thu, 28 Apr 2016 18:16:07 +0000 Received: from localhost by e06smtp06.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 28 Apr 2016 19:16:04 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp06.uk.ibm.com (192.168.101.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 28 Apr 2016 19:16:02 +0100 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: arnez@linux.vnet.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id C0AA11B08067 for ; Thu, 28 Apr 2016 19:16:49 +0100 (BST) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u3SIG1eS59244788 for ; Thu, 28 Apr 2016 18:16:01 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u3SIG03p011938 for ; Thu, 28 Apr 2016 12:16:01 -0600 Received: from oc1027705133.ibm.com (dyn-9-152-212-143.boeblingen.de.ibm.com [9.152.212.143]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u3SIG0rL011901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2016 12:16:00 -0600 From: Andreas Arnez To: Pedro Alves Cc: Ulrich Weigand , gdb-patches@sourceware.org Subject: Re: [PING][PATCH 2/2] Involve gdbarch in taking DWARF register pieces References: <20160415180943.4FEE857EE@oc7340732750.ibm.com> <571134CD.8080507@redhat.com> <5714E6EA.8050905@redhat.com> <57150356.3090508@redhat.com> Date: Thu, 28 Apr 2016 18:16:00 -0000 In-Reply-To: (Andreas Arnez's message of "Thu, 28 Apr 2016 18:51:27 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16042818-0025-0000-0000-000017610B6C X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00646.txt.bz2 On Thu, Apr 28 2016, Andreas Arnez wrote: > On Thu, Apr 28 2016, Pedro Alves wrote: > >> I'd naively think that the fix for something like that would be >> to make dwarf_reg_to_regnum return the gdb FP register number instead >> of the vector number, when the type fits in a FP register, instead of >> the need for an extra diversion step. Ignoring the fact that we don't >> currently pass the type/size to gdbarch_dwarf_reg_to_regnum. > > Right, ignoring that fact ;-) > > Also, IMHO the "actual" placement of an object within a register does > not conceptually depend on where the register number came from. It > could come from DWARF, from some other debug format, from the user, or > from wherever. Adjusting the placement only for objects with a DWARF > location seems wrong to me. There's another aspect I should probably mention here. The adjustment of the register number in this gdbarch method is really just a circumvention around the register cache's inability of representing *partially* valid registers. Otherwise unwinding would result in the first 64 bits of such a vector register being "valid" and the others "invalid", and then we could slice any value types from the valid bits. In the long run maybe we want to extend the regcache in such a direction, but I didn't see that in the scope of this fix. -- Andreas