From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id k9k9I3wwFGB9JAAAWB0awg (envelope-from ) for ; Fri, 29 Jan 2021 10:57:48 -0500 Received: by simark.ca (Postfix, from userid 112) id 837361EF80; Fri, 29 Jan 2021 10:57:48 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C7A681E945 for ; Fri, 29 Jan 2021 10:57:47 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 780B93938C31; Fri, 29 Jan 2021 15:57:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 780B93938C31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611935867; bh=kbyAC1T6QrvBi76SP6oe8iMn1FFGjY3jE0rEMpTXHAU=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=wHZRkYsnTh3/2nBJdRgY2bUnRopZBAd0RQKgR9vGCgeGQkSgo7hRXb1ckOr0lsqwV RKoxzRJZbyyvBww515l8IH/UxM2M5yq1KgoyX5D6u7FiK9I/2T/kyNfsLrfe10DCld vh6XTx+AOzGvZ1hbGIBAHt9+ZuTc+Nz360eNC1Q4= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 04891385481F for ; Fri, 29 Jan 2021 15:57:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 04891385481F Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 10TFvKRO000566 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Jan 2021 10:57:25 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 10TFvKRO000566 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id AC18C1E945; Fri, 29 Jan 2021 10:57:20 -0500 (EST) Subject: Re: [PATCH 10/13] gdb/testsuite: add .debug_loclists tests To: Zoran Zaric , gdb-patches@sourceware.org References: <20210120053925.142862-1-simon.marchi@polymtl.ca> <20210120053925.142862-11-simon.marchi@polymtl.ca> <6fe96ff5-3f11-585c-0331-62d1fe234bd2@amd.com> <56f87bf1-a43a-a710-005a-502101412d35@polymtl.ca> <491bdd1e-4ea5-eefc-0cc9-173e1fd8efc0@amd.com> Message-ID: Date: Fri, 29 Jan 2021 10:57:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <491bdd1e-4ea5-eefc-0cc9-173e1fd8efc0@amd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 29 Jan 2021 15:57:20 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-01-29 5:13 a.m., Zoran Zaric wrote: >>>> >>>> Add tests for the various issues fixed in the previous patches. >>>> >>>> Add a new "loclists" procedure to the DWARF assembler, to allow >>>> generating .debug_loclists sections. >>>> >>> >>> Thank you for this contribution. >>> >>> Having a loclists support in DWARF assembler gives us so considerable testing flexibility and decouples the gdb testing even more from what compiler is expected to generate. >>> >>> The only thing missing now (at least in my mind) is the CFI support but that is a big project for the future. >> >> Given that: >> >> - the actual assembler (GNU as or other) already has support for >> specifying and generating CFI, and >> - a test case that wants to use specific CFI would contain some >> assembly code already, to control exactly which instructions are >> generated > > This is not exactly true, you can always define a CFI that doesn't need any assembly code considering that register values can be set from the the test itself or if only CFI register rules that target a memory locations are used. Isn't a CFI table essentially a big mapping that says: - At address X + 0, here's how you'll find the saved registers - At address X + 2, here's how you'll find the saved registers - ... and so on So ultimately you want in your test case to know exactly which instructions are generated, and their addresses, to generate the CFI table, don't you? And for that, won't you write assembly? I'm not sure I know what "CFI register rules that target a memory location" means. A register from a previous frame that is currently saved in memory? I don't really understand what that changes. > With the new extensions that I've contributed (and are currently under the review) the register rules mechanism now supports any location description to be part of the DWARF expression. With this extension, you can imagine that a very complex DWARF expression that doesn't use any potentially ABI sensitive resource, can still be written and tested in the same way as any variable location. Hmm but in the end it's still just a sequence of opcodes, isn't it? If a compiler is to ever emit such an expression, it would have to emit it using CFI directives in the assembly code, so we could always write the same expression by hand directly in assembly, couldn't we? > Another option is to only hand write a CFI table for the top level function (frame 0) and design a way to merge the original CFI generated by the compiler for other functions with the hand written one. I don't remember how exactly things are merged by the linker, but I suppose that would work. But again, you'd probably want to write that top-level frame 0 function in assembly - I think. Or if don't need to write different rules for different instructions in the function, I guess that function could be written in C, and you make CFI rules for the whole function's range. But you'd need a way to tell the compiler to not generate CFI for that particular function. > > Also, with a potential new operation DW_OP_LLVM_call_frame_entry_reg described at length here: > > https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html > > This would allow us to test any CFI expression of the frame we are currently stopped in. > >> >> I don't think our assembler needs to know how to generate CFI, you'd >> just write it in platform-specific assembly. >> > > But, isn't this the case for any part of the DWARF assembler functionality? > > Writing any complex DWARF expression fast in any assembly is hard and time consuming. No, you can't express symbolically any DWARF expression at the assembly level. For example, you can't describe the tree of DWARF DIEs using directives in assembly. All you can do is output the raw bytes using the .byte and friends directives, but that wouldn't be humanly feasible. So instead we have this higher level language (our DWARF assembler) where we describe the tree of DIEs and have it output the .byte directives for us. But in the case of CFI, the assembler has directives to express symbolically everything we need to express today: the directives ".cfi_def_cfa_offset" and friends. You write them interleaved with the assembly code, and the assembler generates the corresponding CFI tables. And this is also how the compiler works, it emits CFI directives interleaved with the assembly code. So if we want to test a particular DWARF CFI construct, it's probably because the compiler generates it, which means the assembler supports it, which means we can also write a test case for it by hand (in assembly). Or maybe I'm mistaken and some compilers generate CFI tables as bytes directly? > > I agree that adding a CFI support requires more thought and effort and better understanding about how the CFI works and what is safe to use from a test writer perspective, but I can definitely see the benefit of adding that support in the future. In the event we want to test a CFI construct that isn't yet supported by the assembler, then it could make sense to write own assembler that emits the right bytes directly. Simon