From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127190 invoked by alias); 18 Jan 2016 16:00:24 -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 127078 invoked by uid 89); 18 Jan 2016 16:00:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=clarification, heading, analyzing, 4.2 X-HELO: e06smtp17.uk.ibm.com Received: from e06smtp17.uk.ibm.com (HELO e06smtp17.uk.ibm.com) (195.75.94.113) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 18 Jan 2016 16:00:20 +0000 Received: from localhost by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 18 Jan 2016 16:00:16 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp17.uk.ibm.com (192.168.101.147) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 18 Jan 2016 16:00:13 -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 b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 670E71B08061 for ; Mon, 18 Jan 2016 16:00:17 +0000 (GMT) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0IG0DJf53739736 for ; Mon, 18 Jan 2016 16:00:13 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0IF0E23020934 for ; Mon, 18 Jan 2016 08:00:14 -0700 Received: from oc1027705133.ibm.com (dyn-9-152-212-188.boeblingen.de.ibm.com [9.152.212.188]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u0IF0D6I020894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jan 2016 08:00:14 -0700 From: Andreas Arnez To: Joel Brobecker Cc: gcc@gcc.gnu.org, gdb@sourceware.org, Ulrich Weigand Subject: Re: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register References: <20160116132653.GF4027@adacore.com> Date: Mon, 18 Jan 2016 16:00:00 -0000 In-Reply-To: <20160116132653.GF4027@adacore.com> (Joel Brobecker's message of "Sat, 16 Jan 2016 17:26:53 +0400") 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: 16011816-0005-0000-0000-00000A0B33AF X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00027.txt.bz2 On Sat, Jan 16 2016, Joel Brobecker wrote: >> After analyzing some test case failures in GCC and GDB I realized that >> there are various problems with the handling of DWARF pieces >> (particularly from registers) in the current implementations of GCC and >> GDB. I'm working on a fix for the GDB part, but first I'd like to check >> whether I'm heading into the right direction -- or what the right >> direction is supposed to be. The article below outlines these issues >> and the suggested solution options. > > This is a very nice and detailed analysis of the current situation. > Thank You! > > I admit that I read through the document fairly rapidly; it does > seem to me, at this point, that the first step might be to get > clarification from the DWARF committee? Or is input from the GCC/GDB > community going to help the discussion with the DWARF committee? I think it would be helpful to form an opinion within the GCC/GDB community first. Then we can open a DWARF issue with a specific change request, if necessary. FWIW, here's my (current) opinion: I don't like option 4.2 ("loose interpretation"), because it doesn't seem to have any significant advantages over 4.3 and is more complex. I'm less sure about 4.3 versus 4.1. Option 4.3 seems more intuitive and may require a bit less code than 4.1, but is not compliant with the current standards' wording and does not support the SPU "preferred slots". And regarding the padding support, I prefer 5.3.1 ("no padding support"). -- Andreas