From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id pkFCMtr4EmCJegAAWB0awg (envelope-from ) for ; Thu, 28 Jan 2021 12:48:10 -0500 Received: by simark.ca (Postfix, from userid 112) id BF1551EF80; Thu, 28 Jan 2021 12:48:10 -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 69B061E945 for ; Thu, 28 Jan 2021 12:48:10 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DF32B3870857; Thu, 28 Jan 2021 17:48:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DF32B3870857 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611856089; bh=gXGjNxpKuloFQZiAY56eVgJ9vxHWdxF1SLpSk9nSlwc=; 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=GSajdKPYWSnlcAwDih91x+7QtJ/ZN8d5YjLmwhf+LrYs8sybIIOchmy21FNzzduPf am95grf2loBjpl33WH4HVsGh06MIO58nudpY/LzTiL4V5HuBIL0WwY1MJFnPOnNxtL hJFxHlZp+0EL8HSXy2Fs97MF0b0f8WMnhxkLkX80= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 1B7573861826 for ; Thu, 28 Jan 2021 17:48:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1B7573861826 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 10SHlxmK011947 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jan 2021 12:48:04 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 10SHlxmK011947 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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8E6961E945; Thu, 28 Jan 2021 12:47:59 -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> Message-ID: <56f87bf1-a43a-a710-005a-502101412d35@polymtl.ca> Date: Thu, 28 Jan 2021 12:47:59 -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: <6fe96ff5-3f11-585c-0331-62d1fe234bd2@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 Thu, 28 Jan 2021 17:47:59 +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-28 11:52 a.m., Zoran Zaric wrote:>> From: Simon Marchi >> >> 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 I don't think our assembler needs to know how to generate CFI, you'd just write it in platform-specific assembly. >> + >> + proc loclists { args } { >> + variable _debug_loclists_addr_size >> + variable _debug_loclists_offset_size >> + variable _debug_loclists_is_64_dwarf >> + >> + parse_args {{"is-64" "false"}} >> + >> + if { [llength $args] != 1 } { >> + error "loclists proc expects one positional argument (body)" >> + } >> + >> + lassign $args body >> + >> + if [is_64_target] { >> + set _debug_loclists_addr_size 8 >> + } else { >> + set _debug_loclists_addr_size 4 >> + } >> + >> + if { ${is-64} } { >> + set _debug_loclists_offset_size 8 >> + set _debug_loclists_is_64_dwarf true >> + } else { >> + set _debug_loclists_offset_size 4 >> + set _debug_loclists_is_64_dwarf false >> + } >> + >> + _section ".debug_loclists" >> + >> + # Count of tables in the section. >> + variable _debug_loclists_table_count 0 >> + >> + # Compute the label name for list at index LIST_IDX, for the current >> + # table. >> + >> + proc _compute_list_label { list_idx } { >> + variable _debug_loclists_table_count >> + >> + return ".Lloclists_table_${_debug_loclists_table_count}_list_${list_idx}" >> + } >> + >> + # Generate one table (header + offset array + location lists). >> + # >> + # Accepts one position argument, BODY. BODY may call the LIST_ >> + # procedure to generate loclists. >> + # >> + # The -post-header-label option can be used to define a label just after the >> + # header of the table. This is the label that a DW_AT_loclists_base >> + # attribute will usually refer to. >> + >> + proc table { args } { >> + variable _debug_loclists_table_count >> + variable _debug_loclists_addr_size >> + variable _debug_loclists_offset_size >> + variable _debug_loclists_is_64_dwarf >> + >> + parse_args {{post-header-label ""}} >> + >> + if { [llength $args] != 1 } { >> + error "table proc expects one positional argument (body)" >> + } >> + >> + lassign $args body >> + >> + # Generate one location list. >> + # >> + # BODY may call the various procs defined below to generate list >> + # entries. They correspond to the location list entry kinds >> + # described in section 2.6.2 of the DWARF 5 spec. >> + # >> + # To define a label pointing to the beginning of the list, use >> + # the conventional way of declaring and defining labels: >> + # >> + # declare_labels the_list >> + # >> + # the_list: list_ { >> + # ... >> + # } >> + >> + proc list_ { body } { >> + variable _debug_loclists_list_count >> + > > I guess that the table and list procedures from loclist and ranglist support couldn't be commonized in some way? > > They do seem considerably different. Yeah, they are similar (once you understand one, it's very easy to understand the other). But they are not identical. So given that we have only two kinds, I think it would just make it more complex for nothing to try to factor out the common parts. If we had 20 kinds, then maybe it would be a different story :). Simon