From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 5F0193857C5B for ; Mon, 21 Sep 2020 13:51:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F0193857C5B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Andrew_Stubbs@mentor.com IronPort-SDR: ZdF7R6ievhHZeFpQYE7uSuJ3Tlsiugo+GJPigAxVMq1g8QP3VJZcYn7jjsAVaHdKBPApjKngW5 /ujgdIMHJJYV+MYx5PxqcSDhsxoOWP2ZpSR4YTak/92V0fy8QVCNyV8jDbAK07AR+qQV1mof6Z B+b8sX4pfWfXI09sPlVb7XH/9welHugHzAGLs60cZCD9THeHsc98BWsf6+jcxAo6IdU0bX/BmC tVZZ6BnyCnh6zqS5V/9TgayD3iNLL9UBXX3f2cQFhM79OL576rvpUazJqjMaK1aoEMf3SU0UA2 GMU= X-IronPort-AV: E=Sophos;i="5.77,286,1596528000"; d="scan'208";a="53086405" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 21 Sep 2020 05:51:45 -0800 IronPort-SDR: P4BEtnOn+oK9woxwpRHntJVvR2L3NoAGtL7WV+xdSbZZIaL7iW57hU2QH54Unvmp3DZJIjttzq KebXG3RXtiD9u6aMFqLfwbbGtw/JSaRSNDmrByA71e5sS7BNwT0X6uRv1BIcE2A8+FItqAHbFd TxfDEM1r7ibmrS4otm36Dm0tTg/gXdLGtEbyKBVlhMs3RwRPw5iVtUHnaqSaEG8ILTmoje38Iq QWiZn/uBN97j7KHU/irHA3ryQMFqaq7LaMuzqQO8QqMdLTNllqmR+mosQOau+bgqhJIqiAVE5B Hds= Subject: Re: [PATCH] dwarf: Multi-register CFI address support From: Andrew Stubbs To: "gcc-patches@gcc.gnu.org" References: <363f6c4b-4c7f-9244-9bf1-dee7e7a42f8c@codesourcery.com> <4b1263f2-ae04-bf9a-4f2b-3da192c0daed@codesourcery.com> Message-ID: Date: Mon, 21 Sep 2020 14:51:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <4b1263f2-ae04-bf9a-4f2b-3da192c0daed@codesourcery.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 13:51:48 -0000 Ping. On 03/09/2020 16:29, Andrew Stubbs wrote: > On 28/08/2020 13:04, Andrew Stubbs wrote: >> Hi all, >> >> This patch introduces DWARF CFI support for architectures that require >> multiple registers to hold pointers, such as the stack pointer, frame >> pointer, and return address. The motivating case is the AMD GCN >> architecture which has 64-bit address pointers, but 32-bit registers. >> >> The current implementation permits program variables to span as many >> registers as they need, but assumes that CFI expressions will only >> need a single register for each frame value. >> >> To be fair, the DWARF standard makes a similar assumption; the >> engineers working on LLVM and GDB, at AMD, have therefore invented >> some new DWARF operators that they plan to propose for a future >> standard. Only one is relevant here, however: DW_OP_LLVM_piece_end. >> (Unfortunately this clashes with an AArch64 extension, but I think we >> can cope using an alias -- only GCC dumps will be confusing.) >> >> My approach is to change the type representing a DWARF register >> throughout the CFI code. This permits the register span information to >> propagate to where it is needed. >> >> I've taken advantage of C++ struct copies and operator== to minimize >> the amount of refactoring required. I'm not sure this meets the GCC >> guidelines exactly, but if not I can change that once the basic form >> is agreed. (I also considered an operator= to make assigning single >> dwreg values transparent, but that hid too many invalid assumptions.) >> >> OK to commit? (Although, I'll hold off until AMD release the >> compatible GDB.) > > Minor patch update, following Tom's feedback. > > Andrew