From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101812 invoked by alias); 15 Apr 2016 18:10:00 -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 101791 invoked by uid 89); 15 Apr 2016 18:09:59 -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_PASS autolearn=ham version=3.3.2 spammy= X-HELO: e06smtp09.uk.ibm.com Received: from e06smtp09.uk.ibm.com (HELO e06smtp09.uk.ibm.com) (195.75.94.105) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 15 Apr 2016 18:09:49 +0000 Received: from localhost by e06smtp09.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 15 Apr 2016 19:09:46 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp09.uk.ibm.com (192.168.101.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 15 Apr 2016 19:09:45 +0100 X-IBM-Helo: d06dlp02.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 027A921902DD for ; Fri, 15 Apr 2016 19:09:23 +0100 (BST) Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u3FI9iJx1049048 for ; Fri, 15 Apr 2016 18:09:44 GMT Received: from d06av07.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u3FI9ihc015780 for ; Fri, 15 Apr 2016 14:09:44 -0400 Received: from oc7340732750.ibm.com (icon-9-164-185-116.megacenter.de.ibm.com [9.164.185.116]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u3FI9hFl015772; Fri, 15 Apr 2016 14:09:43 -0400 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 4FEE857EE; Fri, 15 Apr 2016 20:09:43 +0200 (CEST) Subject: Re: [PATCH 2/2] Involve gdbarch in taking DWARF register pieces To: arnez@linux.vnet.ibm.com (Andreas Arnez) Date: Fri, 15 Apr 2016 18:10:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, Ulrich.Weigand@de.ibm.com (Ulrich Weigand) In-Reply-To: <1460716939-27850-3-git-send-email-arnez@linux.vnet.ibm.com> from "Andreas Arnez" at Apr 15, 2016 12:41:39 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20160415180943.4FEE857EE@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16041518-0037-0000-0000-00000AF40696 X-SW-Source: 2016-04/txt/msg00363.txt.bz2 Andreas Arnez wrote: > On s390, when a 'long double' variable is located in a pair of FP > registers, its DWARF location looks something like this: > > DW_OP_reg24 (f8); DW_OP_piece: 8; DW_OP_reg25 (f10); DW_OP_piece: 8 > > If the target has a vector facility, each of its FP registers is > embedded left-aligned in a vector register with the same identical DWARF > register number. But GDB always takes a register piece from the "least > significant" end, which is exactly opposite from where the FP register > is embedded. This mismatch causes a regression with store.exp. > > This change fixes this issue by taking s390 vector register pieces from > the left end instead. Since this requires a suitable gdbarch interface, > the gdbarch method 'value_from_register' is replaced by a new method > 'register_part' with similar functionality, but a slightly different > interface. This method is then invoked in read_pieced_value and > write_pieced_value. I agree it makes sense to use the same gdbarch-provided information in both places here. > gdb/ChangeLog: > > * gdbarch.sh (value_from_register): Remove. > (register_part): New. > * gdbarch.c: Regenerate. > * gdbarch.h: Likewise. > * dwarf2loc.c (read_pieced_value): Get arch-specific placement of > a register piece from the new gdbarch method register_part. > (write_pieced_value): Likewise. > * value.h (default_value_from_register): Remove. > (default_register_part): Declare. > * findvar.c (default_value_from_register): Remove. > (default_register_part): New. > (value_from_register): Call gdbarch_register_part instead of > gdbarch_value_from_register. > (address_from_register): Likewise. > * s390-linux-tdep.c (s390_value_from_register): Remove. > (s390_register_part): New. > (s390_gdbarch_init): Set new gdbarch method register_part instead > of value_from_register. > * spu-tdep.c (spu_value_from_register): Remove. > (spu_register_part): New. > (spu_gdbarch_init): Set new gdbarch method register_part instead > of value_from_register. This is OK. Thanks, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com