From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82371 invoked by alias); 26 Jan 2016 11:57:44 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 82271 invoked by uid 89); 26 Jan 2016 11:57:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Hx-languages-length:2369, bearing, living, it! X-HELO: e06smtp10.uk.ibm.com Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 26 Jan 2016 11:57:41 +0000 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Jan 2016 11:57:37 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 26 Jan 2016 11:57:25 -0000 X-IBM-Helo: d06dlp02.portsmouth.uk.ibm.com X-IBM-MailFrom: arnez@linux.vnet.ibm.com X-IBM-RcptTo: gdb@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 6EBCA2190046 for ; Tue, 26 Jan 2016 11:57:12 +0000 (GMT) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0QBvPLg9240882 for ; Tue, 26 Jan 2016 11:57:25 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0QBvOlj015236 for ; Tue, 26 Jan 2016 04:57:24 -0700 Received: from oc1027705133.ibm.com (dyn-9-152-212-180.boeblingen.de.ibm.com [9.152.212.180]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u0QBvN7e015205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2016 04:57:24 -0700 From: Andreas Arnez To: Matthew Fortune Cc: "gcc\@gcc.gnu.org" , "gdb\@sourceware.org" , Ulrich Weigand , Maciej Rozycki Subject: Re: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register References: <6D39441BF12EF246A7ABCE6654B023536A70637C@LEMAIL01.le.imgtec.org> Date: Tue, 26 Jan 2016 11:57:00 -0000 In-Reply-To: <6D39441BF12EF246A7ABCE6654B023536A70637C@LEMAIL01.le.imgtec.org> (Matthew Fortune's message of "Mon, 25 Jan 2016 22:01:47 +0000") 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: 16012611-0041-0000-0000-0000070E7F97 X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00055.txt.bz2 On Mon, Jan 25 2016, Matthew Fortune wrote: > My dwarf knowledge is not brilliant but I have had to recently consider > it for MIPS floating point ABI changes aka FPXX and friends. I don't know > exactly where this fits in to your whole description but in case it has > a bearing on this we now have the following uses of DW_OP_piece: > > 1) double precision data split over two 32-bit FPRs > Uses a pair of 32-bit DW_OP_piece (ordered depending on endianness). > > 2) double precision data in one 64-bit FPR > No need for DW_OP_piece. > > 3) double precision data that may be in two 32-bit FPRs or may be in > one 64-bit FPR depending on hardware mode > Uses a single 64-bit DW_OP_piece on the even numbered register. Hm, so in 32-bit hardware mode the DWARF consumer is expected to treat the DW_OP_piece on the even numbered register as if it were two pieces from two consecutive registers? Or should we rather consider the even numbered register to be 64 bit wide, where the right half shadows the next odd-numbered register? If so, I believe you generally want pieces from FPRs to be taken from the left, correct? > I'm guilty of not actually finishing this off and doing the GDB side but > the theory seemed OK when I did it! From your description this behaviour > best matches DW_OP_piece having ABI dependent behaviour which would make > it acceptable. These three variations can potentially exist in the same > program albeit that (1) and (3) can't appear in a single shared library > or executable. It's all a little strange but the whole floating point > MIPS o32 ABI is pretty complex now. I don't quite understand why (1) and (3) can not coexist in the same shared library or executable. Can you elaborate a bit? I'm curious about the interaction with vector registers. AFAIK, vector registers on MIPS also embed the FPRs (left or right?). Are the same DWARF register numbers used for both? And when taking a 64-bit DW_OP_piece from a vector register, would this piece correspond to the embedded FPR? Also, how do you think that the following should be represented in DWARF: * Odd-sized bit field in one of a vector register's elements; * odd-sized bit field spilled into an FPR; * single-precision `complex float' living in two consecutive 64-bit FPRs. Thanks for your input! -- Andreas