From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id E6F623950C6E for ; Thu, 4 Mar 2021 00:35:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E6F623950C6E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from librem (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id A8FDE304319B; Thu, 4 Mar 2021 01:35:11 +0100 (CET) Received: by librem (Postfix, from userid 1000) id B2910C1C80; Thu, 4 Mar 2021 01:33:57 +0100 (CET) Date: Thu, 4 Mar 2021 01:33:57 +0100 From: Mark Wielaard To: Tom de Vries Cc: dwz@sourceware.org, jakub@redhat.com Subject: Re: [PATCH] Fix .debug_line reference above end of section Message-ID: <20210304003357.GL3014@wildebeest.org> References: <20210302135713.GA22526@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210302135713.GA22526@delia> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, 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: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 00:35:14 -0000 Hi Tom, On Tue, Mar 02, 2021 at 02:57:14PM +0100, Tom de Vries wrote: > Consider the file test-import-repeatedly from PR26738, combined with a trivial > a.out: > ... > $ cp test-import-repeatedly 1 > $ gcc -m32 -g ~/hello.c > $ cp a.out 2 > ... > > When doing multifile optimization, we run into: > ... > $ dwz -m 3 2 1 > dwz: 3: .debug_line reference above end of section > ... > > Using --devel-save-temps and src/contrib/gen-dwz-debug-all.sh we get the > unoptimized multifile, and find there a CU: > ... > Compilation Unit @ offset 0x371: > Length: 0x6d (32-bit) > Version: 4 > Abbrev Offset: 0x14d > Pointer Size: 4 > <0><37c>: Abbrev Number: 1 (DW_TAG_compile_unit) > <37d> DW_AT_stmt_list : 0xda > <381> DW_AT_language : 0 (Unknown: 0) > <382> DW_AT_comp_dir : ./build-3.8 > ... > which refers to a .debug_line offset 0xda, but the debug_line section only > contains an entry at offset 0x0. I was unable to replicate this, so it is a little harder to comment in this. I don't fully understand why this happens, is this because of something in the input file or because we move all DIEs with file attributes? Would it be possible to attach the various temp files to the bug report? > This can be explained as follows. The DIEs written into the CU do not > contain a single DW_AT_decl_file. Consequently, htab_line will be NULL once > we get here in write_multifile: > ... > || (line_htab != NULL && write_multifile_line ())) > ... > and no .debug_line contribution will be added. However, the CU DIE > referencing the .debug_line contribution is written regardless. > > We could fix this by not writing the DW_AT_stmt_list for the CU DIE in this > case, but that would require changing the order in which abbreviations are > computed. > > Instead, fix this conservatively, by removing "line_htab != NULL &&", such we > get a minimal .debug_line contribution. This does look technically OK. write_multifile_line does handle line_htab == NULL correctly and sets up multi_line_off which will be used to write the DW_AT_stmt_list. But if the CU doesn't have a DW_AT_stmt_list this will produce an unnecessary line table (stub). I cannot immediately see whether this is an odd corner case that normally wouldn't happen in practice or if that could happen more often. Cheers, Mark