From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id AA96B384BC30 for ; Thu, 4 Mar 2021 08:33:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AA96B384BC30 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C4AA3AD2B; Thu, 4 Mar 2021 08:33:43 +0000 (UTC) Subject: Re: [PATCH] Fix .debug_line reference above end of section To: Mark Wielaard Cc: dwz@sourceware.org, jakub@redhat.com References: <20210302135713.GA22526@delia> <20210304003357.GL3014@wildebeest.org> From: Tom de Vries Message-ID: <9bda5bfa-b2dc-84e5-df99-0c62929b934b@suse.de> Date: Thu, 4 Mar 2021 09:33:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210304003357.GL3014@wildebeest.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 08:33:46 -0000 On 3/4/21 1:33 AM, Mark Wielaard wrote: > 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? > This is because all the DIEs from the input file that are written into the unoptimized multifile don't have any attributes referring to the file table. > Would it be possible to attach the various temp files to the bug > report? > Done. >> 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). Ack. The fix is conservative. > 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. I've seen this error before, so it's not completely cornercase. Thanks, - Tom