From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21378 invoked by alias); 11 Feb 2016 17:04:21 -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 21351 invoked by uid 89); 11 Feb 2016 17:04:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*r:sk:gdb@sou X-HELO: e06smtp13.uk.ibm.com Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Thu, 11 Feb 2016 17:04:19 +0000 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Feb 2016 17:04:16 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 11 Feb 2016 17:04:15 -0000 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: arnez@linux.vnet.ibm.com X-IBM-RcptTo: gdb@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 D90EF1B0805F for ; Thu, 11 Feb 2016 17:04:28 +0000 (GMT) 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 u1BH4EeG28901530 for ; Thu, 11 Feb 2016 17:04:14 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 u1BH4Eub029518 for ; Thu, 11 Feb 2016 10:04:14 -0700 Received: from oc1027705133.ibm.com (dyn-9-152-212-180.boeblingen.de.ibm.com [9.152.212.180]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u1BH4D5X029471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2016 10:04:13 -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> <6D39441BF12EF246A7ABCE6654B023536A743373@LEMAIL01.le.imgtec.org> Date: Thu, 11 Feb 2016 17:04:00 -0000 In-Reply-To: <6D39441BF12EF246A7ABCE6654B023536A743373@LEMAIL01.le.imgtec.org> (Matthew Fortune's message of "Thu, 11 Feb 2016 12:18:13 +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: 16021117-0013-0000-0000-000008983ACF X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00014.txt.bz2 On Thu, Feb 11 2016, Matthew Fortune wrote: > No I think this is backwards it is the left half that shadows the next > register and pieces are taken from the right. I've attempted a description > below to see if it helps. > > I don't believe (in the MIPS case) we could unconditionally view the even > numbered register as 64-bit or 32-bit as the shadowing onto the next > register only exists in some hardware modes. > > The size of a register has to be determined from the current hardware mode > and then the logic would be to read as much as possible from the referenced > register and use it as the lower bits of the overall value. Then continue > reading consecutive registers filling the next most significant bits > until the full size of the DW_OP_piece has been read. This for MIPS > FP registers is endian agnostic as the higher numbered register always > has the most significant bits. For GPRs the even numbered register will > provide either the most or least significant bits depending on endian but > we have no reason to use this paradoxical DW_OP_piece for GPRs as they > have compile time deterministic size. Hm, so in the shadowed case, assuming that the DWARF consumer has loaded the register file into a byte array via ptrace, which bytes would the DW_OP_bit_piece offsets for FPR n correspond to? Is it like this for little-endian? FPR n FPR n+1 +---+---+---+---+ +---+---+---+---+ | | | | | | | | | | +---+---+---+---+ +---+---+---+---+ 0 8 16 24 32 40 48 56 (In which case pieces would be taken from the left.) Or different? And for big-endian? -- Andreas