From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123983 invoked by alias); 28 Apr 2016 16:51:45 -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 123966 invoked by uid 89); 28 Apr 2016 16:51:45 -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=illustrates, art 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 16:51:35 +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 17:51:31 +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 17:51:29 +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 b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 50EB41B0805F for ; Thu, 28 Apr 2016 17:52:16 +0100 (BST) Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u3SGpSmE2687470 for ; Thu, 28 Apr 2016 16:51:28 GMT Received: from d06av09.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u3SGpRXS032200 for ; Thu, 28 Apr 2016 10:51:28 -0600 Received: from oc1027705133.ibm.com (dyn-9-152-212-143.boeblingen.de.ibm.com [9.152.212.143]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u3SGpRBx032186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2016 10:51:27 -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 16:51:00 -0000 In-Reply-To: (Pedro Alves's message of "Thu, 28 Apr 2016 15:47:14 +0100") 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: 16042816-0025-0000-0000-0000175F2CC5 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00640.txt.bz2 On Thu, Apr 28 2016, Pedro Alves wrote: > I couldn't find any reference to "sub-register" in the codebase. > I'd assume it's something like "eax" being a sub part of "rax" > on x86-64. But I'm not certain that's the case here? On a machine with > vector registers, is a FP register really a chunk of the vector > register, or is it a real separate physical register? It's exactly comparable with eax and rax. Or consider the SSE registers xmm0-xmm15, which are embedded in their double-wide AVX counterparts ymm0-ymm15. With z/Architecture, each 64-bit FP register is just a "chunk" ("sub-register" / "part" / "slice" / ...) of a 128-bit vector register. The ASCII art in section 2.1 of this article illustrates this: https://sourceware.org/ml/gdb/2016-01/msg00013.html (BTW, I still didn't get much feedback on that article...) And if there is a better (or wider used) term than "sub-register", I'll be happy to change the wording. > My main confusion revolves I think, around how these points > are addressed: > > - FP registers and vector registers have the same identical > DWARF register number. > > - If the object stored is <= 8 bytes, we should find it in > the FP register; otherwise get it from the vector register. > > 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. -- Andreas