From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id lAvrHPF1D2BVFQAAWB0awg (envelope-from ) for ; Mon, 25 Jan 2021 20:52:49 -0500 Received: by simark.ca (Postfix, from userid 112) id 62D441EF80; Mon, 25 Jan 2021 20:52:49 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [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 6B0401E945 for ; Mon, 25 Jan 2021 20:52:48 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EFB62385ED4C; Tue, 26 Jan 2021 01:52:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EFB62385ED4C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611625968; bh=koLnvn3tWP3dMN7q8+Nao4ZzdqxVqzwX1bZmzDZJZJw=; 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=UGZQxyv2u+GGR6zA0AW3CogG7NkGuKGvUU6SSavp45c7Zd4gffT5WmAG6mA1hX+K9 76bgRBvBOYwtgumtRPCCYUR6iR9vtarSeN2dTcxe0GkRLr2raWsPEgj9nJnKE1sPfs xTDSwfG5XPIxiTps3waXKLeHlh+iarTzdfGf9+ok= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id AE719385ED4C for ; Tue, 26 Jan 2021 01:52:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AE719385ED4C 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 10Q1qbk3013351 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Jan 2021 20:52:42 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 10Q1qbk3013351 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 E78341E945; Mon, 25 Jan 2021 20:52:36 -0500 (EST) Subject: Re: [PATCH][gdb/symtab] Handle DW_AT_ranges with DW_FORM_sec_off in partial DIE To: Bernd Edlinger , Tom de Vries , gdb-patches@sourceware.org References: <20210125122444.GA15885@delia> <56f38801-477e-fa38-5e16-22a4ed73437c@polymtl.ca> Message-ID: Date: Mon, 25 Jan 2021 20:52:36 -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: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 26 Jan 2021 01:52:37 +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: Tom Tromey Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-01-25 1:53 p.m., Bernd Edlinger wrote: > On 1/25/21 7:12 PM, Simon Marchi wrote: >> >> >> On 2021-01-25 12:42 p.m., Bernd Edlinger wrote: >>> On 1/25/21 5:36 PM, Simon Marchi wrote: >>>>> Yes, unfortunately I have not any experience with writing such assembly >>>>> tests, but I am always impressed when one of you does it though :-) >>>>> >>>>> Nevertheless, the test case seems to be stable from gcc-4.8 .. gcc-11, >>>>> that it fails without the patch and passes with the patch. >>>>> >>>>> So is it okay to push my partial symbols test as-is? >>>> >>>> My patch here adds a test that uses DW_FORM_sec_offset to point >>>> to a .debug_rnglists (DWARF5) section. Maybe that's sufficient, >>>> but if not I could probably do a DWARF4 equivalent. >>>> >>>> https://sourceware.org/pipermail/gdb-patches/2021-January/175229.html >>>> >>> >>> Yeah, the hardest part on a one-line change like this is always the test case. >>> >>> So, I tried this patch on current trunk, but it fails: >>> >>> Running /home/ed/gnu/gdb-build-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.dwarf2/rnglists-multiple-cus.exp ... >>> ERROR: Couldn't load rnglists-multiple-cus-dw32 into GDB (GDB internal error). >>> ERROR: Couldn't load rnglists-multiple-cus-dw64 into GDB (GDB internal error). >>> Running /home/ed/gnu/gdb-build-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.dwarf2/rnglists-sec-offset.exp ... >>> FAIL: gdb.dwarf2/rnglists-sec-offset.exp: is_64=false: p/x &foo >>> FAIL: gdb.dwarf2/rnglists-sec-offset.exp: is_64=true: p/x &foo >>> >>> This probably means that your test tests more than this single-line change alone? >> >> Hmm, with current master (so with Tom's patch merged), >> gdb.dwarf2/rnglists-sec-offset.exp passes for me. >> > > That will probably need investigation. > Let's first check if I applied the corrrect test case, > see attached patch.txt. It looks like the right patch (I looked at your second patch.txt). > > tried to do "readelf --debug-dump rnglists-sec-offset-dw32" and > "readelf --debug-dump rnglists-sec-offset-dw64" > > I used GNU readelf (GNU Binutils) 2.35.1 > > I see a warning: > readelf: Warnung: The .debug_rnglists section contains unsupported offset entry count: 2. > > > what does that mean? > Doesn't that indicate that the debug-info somehow wrong? I think it's more that readelf is not yet able to read .debug_rnglists sections with an array of offsets (used when you want to use the DW_FORM_rnglistx form), probably because gcc does not use produce / use it. llvm-dwarfdump can dump it: $ llvm-dwarfdump --debug-rnglists testsuite/outputs/gdb.dwarf2/rnglists-sec-offset/rnglists-sec-offset-dw32 testsuite/outputs/gdb.dwarf2/rnglists-sec-offset/rnglists-sec-offset-dw32: file format elf64-x86-64 .debug_rnglists contents: range list header: length = 0x00000034, format = DWARF32, version = 0x0005, addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x00000002 offsets: [ 0x00000008 0x0000001a ] ranges: [0x0000000000004000, 0x0000000000005000) [0x0000000000004000, 0x0000000000004010) Notice "offset_entry_count = 0x00000002" and the two offsets in the array of offsets. > It happens pretty reliably when you have a function that contains an error > handling that looks obvously "unlinkely" to the compiler, because it is guarded > by an if-condition and calls abort(), while there are also code paths that > don't call about. The parts that call abort are then in a separate cold section. Indeed. I think it's good to have some tests with optimized code (in addition to those that use the DWARF assembler), but we can't be too specific about what we expect the generated code to look like. For example, whether a given function is inlined or whether a function is split in two. But at least, we can check that we can put a breakpoint on the function and run there, that is always supposed to work. And perhaps a new crazy optimization in GCC version n + 1 will make that simple use case break, so that will notify us that need to support something we don't support currently. Simon