From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kd0VDupHEmkynjMAWB0awg (envelope-from ) for ; Mon, 10 Nov 2025 15:15:38 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=uyNJvu32; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 35CE91E0B8; Mon, 10 Nov 2025 15:15:38 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 9DFC71E04C for ; Mon, 10 Nov 2025 15:15:37 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2CDA53858D3C for ; Mon, 10 Nov 2025 20:15:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2CDA53858D3C Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=uyNJvu32 Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 3EF0E3858D1E for ; Mon, 10 Nov 2025 20:15:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3EF0E3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3EF0E3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762805702; cv=none; b=iTUKxvYC73rMkaMsu90typTc3lPsyWBMhuS37mN6/6XtgJt6gnID0V6HEknYJBSY8i/m96M2ILvspPupnHnJQd/46TsY05ZO17c4ISM3wnj14VCAEWQP+NKqgiOBHkv/1BY/m6QCtJ2kwCV6kMsG102XLRGURwcewA0bfzDtG80= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762805702; c=relaxed/simple; bh=hSOAgj7gA7wCy7N1eQQnJ2F7UZ0luw8eNUbRoXw0Wrc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=S1HeAmftYhlKoHa0fVDKZtlXgZAtp9XQ1VlPUWpThYk1XsdpIpG0JH/pL7pu+z5WDjQ0NvlEG5eZ24riVw2fNAYkswXBUWDt4wRB3ypV14Z10HFdnhEbG4KANyo+ATSFKHB5zV2KK4Zk56tSwBx5c7hDlumCl/hPDDODa2Hn9J4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3EF0E3858D1E 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 5AAKEuie162275 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Nov 2025 15:15:00 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 5AAKEuie162275 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1762805701; bh=DT0GxV8QMb5AHQAyrsUVbKA7qSQkku6eazcP96Dj0/I=; h=Date:Subject:To:From:In-Reply-To:From; b=uyNJvu320XrhMNgAssAtD76+OkGYCJZzBdcMf4+DE+zvnx51Wdzy5h9nX805WsAaq NehR+9cjjhJdgpx91gLaDeo+2KDGci5Y/LEsRDSewFMtU/Xqy2LofpW7OlDNpay6Zy Gzqk7DBt6GgxM3JGYsmqy2+LwHaQjUgo9ZZ7t8aM/Z2I8fqbMbZZg28A0Er2KA6ZqQ 6g/Var+HJUe6zZtgwHenbMUjGdlnzaPJiCfJVqz+FrSl4tB60bgIShX9JRH/PAGMos HYl2yKrarKYKBBDmNHY6QD4+TJP6C6QDor6bqbl8EZhBFLvbPI469oqjX5rj+ZOt0Z WRWrP5lPQNpaw== Received: by simark.ca (Postfix) id BBC4E1E04C; Mon, 10 Nov 2025 15:14:55 -0500 (EST) Message-ID: Date: Mon, 10 Nov 2025 15:14:55 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] gdb/testsuite/dwarf: use single abbrev table in .dwo files To: Simon Marchi , gdb-patches@sourceware.org References: <20251107211041.520697-1-simon.marchi@efficios.com> <20251107211041.520697-2-simon.marchi@efficios.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20251107211041.520697-2-simon.marchi@efficios.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 10 Nov 2025 20:14:56 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 11/7/25 4:10 PM, Simon Marchi wrote: > From: Simon Marchi > > When I wrote test gdb.dwarf2/fission-with-type-unit.exp, I did not use > build_executable_and_dwo_files, because it wouldn't work to have > multiple units in the .dwo file, each referring to their own abbrev > table using labels. build_executable_and_dwo_files extracts the .dwo > file content from the .o using objcopy (just like gcc does, I learned), > meaning that the .dwo file never runs through a linker. Anything > needing relocation (like labels pointing to abbrev tables) doesn't work. > > I instead opted to use gdb_compile_shlib to build the .dwo file on its > own, so that those labels would get resolved. That causes problems now > that I'm trying to write a test with multiple type units in a .dwo file, > where each type unit should be in its own .debug_types section. Running > the .dwo file through the linker causes all the .debug_types section to > be collapsed into one. And generally, I think it was a bad idea to > generate a .dwo file using the linker, since the idea behind .dwo files > is that they do not need to be linked (therefore improving link > times). We want to produce files as close to what an actual compiler > would produce. > > This patch fixes this by doing what compilers do in the same situation: > use a single abbrev table shared by all units in the .dwo file. This > requires the following changes in lib/dwarf.exp: > > - Declare a new variable _dwo_abbrev_num, which holds the next > abbrev number to use in the .dwo file's abbrev section > (.debug_abbrev.dwo). Initialize this variable to 1. > - When producing a CU or TU in a .dwo file, use 0 as the abbrev table > offset. > - When generating a DIE, return $_dwo_abbrev_num or $_abbrev_num, > depending on whether the current CU is in a .dwo file. > - After producing a CU or TU in a .dwo file, don't append the > terminator byte. > - After finishing producing the CUs and TUs, append the terminator byte > in .debug_abbrev.dwo if we did output anything there. > > Update gdb.dwarf2/fission-with-type-units.exp to use > build_executable_and_dwo_files, as it should. I spotted that running this test with the cc-with-gdb-index board now shows a new internal error. I just wanted to note that this is not a regression, it's actually the test going further and catching an actual bug in GDB. Please consider that the following text is appended to the commit message. --- With this change, running with the cc-with-gdb-index board, I see: (gdb) maint expand-symtabs /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3056: internal-error: cutu_reader: Assertion `sig_type->signature == cu->header.signature' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs (GDB internal error) This is actually an improvement, as the test case didn't run properly before. The compilation failed with: gdb compile failed, During symbol reading: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0xc [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/.tmp/fission-with-type-unit] The reason was that the old code would try to generate the GDB index during this step: # Build main file. if { [build_executable "${testfile}.exp" $binfile \ [list ${srcfile} ${main_asm_file}] {nodebug}] } { return } ... which is even the DWO file is even generated. With this patch things are done in the correct order: - The -dw.S file is generated - The -dw.o file is compiled from the -dw.S - The .dwo sections are extracted to the .dwo file, and stripped from the -dw.o file - The executable is linked from the .o and -dw.o - gdb-add-index is ran on the executable When gdb-add-index runs, the .dwo file exists, so GDB is able to produce an index. That index is bogus though, because the .gdb_index format is unable to describe skeletonless type units. And then GDB gets confused trying to use that index, leading to the internal error. --- Simon