From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 188C03857C6C for ; Mon, 5 Oct 2020 10:07:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 188C03857C6C 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: a6Eq7OL+lOyUxAmaGAeetDyWVelONPik2eut5qaLeDl/bzUrQAJWdhMDPIpjswVKshK1aW7L50 5CCWdRfRMxMecSCj8iuubhvkFBjTgF7UQsLueLYhtd7dJHPIGXU+mK1SmOfcGi+Mg6DvFD3Inp Dwrn8tsVJ8o4nbIDYrAUaiEj9+/0/dfF02GN70vdABTRkb0UceIILEZ1j+wJiR19op6uhJd5Mh QqDV6T456BFm7AnfNaICX3bSHXwcP/sLvHng7b9z8E7mUqMVlI9jzs8GocsF1BvdDhDVKyB5ab SlU= X-IronPort-AV: E=Sophos;i="5.77,338,1596528000"; d="scan'208";a="53710226" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 05 Oct 2020 02:07:35 -0800 IronPort-SDR: r0B611p27qKYOq1yfQz2cqL1Z1J+jwrY1baK4cfAi2Amo1+7RNzT/jSa28JNraEXWz7s7XrF7k F5dUBy7wN2ErLjcIDcgpbLssgf6w0+rUMDM24rVHNfeuzfcgCaTXepLUOJbDoSWcgKRw1whei5 h72yWQs8c4+RPQ3ZjwJm7k18BchUikG4k7V2Nu5G4sacpeFzQSX/+30F08FGpRq10+ebNyDPnz dkPvijVXy9YKrBJ2xqDmCgtDCgNDShuBkDY20OQz9exzyjQ+HDLx1L+0WOCTrinWa6VLMLv16K ewA= 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: <725256d9-4713-7a32-30d9-154d2c0779a4@codesourcery.com> Date: Mon, 5 Oct 2020 11:07:24 +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: 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-06.mgc.mentorg.com (139.181.222.6) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.4 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, 05 Oct 2020 10:07:37 -0000 Ping. On 21/09/2020 14:51, Andrew Stubbs wrote: > 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 > >