From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76760 invoked by alias); 25 Jan 2016 22:01:53 -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 76720 invoked by uid 89); 25 Jan 2016 22:01:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=unavailable version=3.3.2 spammy=settle, brilliant, numbered, bearing X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Jan 2016 22:01:51 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Websense Email Security Gateway with ESMTPS id C66C7354E2382; Mon, 25 Jan 2016 22:01:45 +0000 (GMT) Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by hhmail02.hh.imgtec.org (10.100.10.20) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 25 Jan 2016 22:01:49 +0000 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0210.002; Mon, 25 Jan 2016 22:01:48 +0000 From: Matthew Fortune To: Andreas Arnez , "gcc@gcc.gnu.org" , "gdb@sourceware.org" CC: Ulrich Weigand , Maciej Rozycki Subject: RE: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register Date: Mon, 25 Jan 2016 22:01:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B023536A70637C@LEMAIL01.le.imgtec.org> References: In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00054.txt.bz2 Andreas Arnez writes: > 6 Summary of Open Questions > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > 1. Out of the standard interpretations discussed under "options" > (section 4) above, which do we want to settle on? Or is the > "preferred" interpretation missing from that list? > 2. Should pieces fully or partially outside their underlying objects > be considered valid or invalid? If valid, how should they be > aligned and padded? In any case, what is the suggested treatment > by a DWARF consumer? 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.=20 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. Matthew