From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CVgEFLp1HGmzmw8AWB0awg (envelope-from ) for ; Tue, 18 Nov 2025 08:33:46 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=gott99Bl; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4B3DE1E0B6; Tue, 18 Nov 2025 08:33:46 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,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=unavailable 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 B716C1E048 for ; Tue, 18 Nov 2025 08:33:45 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 59DCB3857358 for ; Tue, 18 Nov 2025 13:33:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 59DCB3857358 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=gott99Bl Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 2276B385772A for ; Tue, 18 Nov 2025 13:32:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2276B385772A Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2276B385772A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763472730; cv=none; b=V4L53M+ZtSSDlKXzthj7BHEOPtyH2TqZIHVCHN16Pk40ruWerwtRLUifxsoLfW9r6b7u+y6sbgy1yGdNFIoqicBLqxkcNlXrYoD3Qy8u/x7Iv6/GY23lqLWvbHDUfwOkVfaYkSTi2fVWPEOql7keil0eSuCNE4kjQoA81VAfCe0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763472730; c=relaxed/simple; bh=n0hzfZu0N40LI9YVqFs0mraeaGiIYF7LKXcbWS02Ffs=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=j6xE503NjocGQ+hAlxfNyruGFQS5bu4jUcMmh1dYaqYJ7ZX+TcCiq7CZuUJV/KAC5EOmaJPGdUD1WKWC3UBHJu2PT/MxNoCdrMv42lLRq/MfFVqjduXmNtWrBju/4aQCec6HemmmsAEL3Z+P7hW5xWiIhN0s7HRYLJHJNbuqUrc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2276B385772A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763472729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7/krtzi2qeMDoWvrWFsuOE0KM3NDq6KOzGT8KXw4zYY=; b=gott99Bl23bWlNlkaHth+NdAiGA128if4kr8fqx54fmy8UormkpJA38w+yZxHGXPLfPDlx VulStRK+z40gY06BqSM3ltv8mTkK43XLpIhhc0yMfA6ZCkmpz9MVZhxztyodXVo5rNG5aq 2gVnoJKLxHCWLKi0+HSQ0CemPUfXjDY= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-267-H-hc07AoNgaZ0MjH1DcBqg-1; Tue, 18 Nov 2025 08:32:08 -0500 X-MC-Unique: H-hc07AoNgaZ0MjH1DcBqg-1 X-Mimecast-MFC-AGG-ID: H-hc07AoNgaZ0MjH1DcBqg_1763472727 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-42b2ffbba05so2911648f8f.0 for ; Tue, 18 Nov 2025 05:32:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763472727; x=1764077527; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7/krtzi2qeMDoWvrWFsuOE0KM3NDq6KOzGT8KXw4zYY=; b=Bpt4g/BD2mqt59UXjv3HNRcXrTe0i1oE7jv69sLP23ANyEb12lW/5uYHIlkSSvR3Vf 1QmfG0blggB3lnKzf/V7w3zFx7Do1hf5sg+p56KhcBID3DZpVsHXRUOnOW70XC8BfMuM KEOkHEN3bKnDxcuvmv4NuGnqcdxj+z1quZN9gxk9NrqjOBQhgHoRE94Vn0r9Kq651WRR mHJLWp9pDzts59NEgmwrEi0jN5jOO7XHDDzYWPFFwKO1a5dTWwVQ9p3W3TpekUNc08vj 8YwOAtFYRbNpkwgGZybAFbEv4bHHh6uwk6u4h/SmUzTXxutQ0oy7v4Y+/40SZNUQnYzP NA3Q== X-Forwarded-Encrypted: i=1; AJvYcCW37peUAFlB0AbZZMIky3e5/afeNlPZ7f11ejlo0yapMw77YwdalR38AlgVu1pNyytftpXNDhuKiqPgnQ==@sourceware.org X-Gm-Message-State: AOJu0Yzq4owOW0rSW6doOr9etKkDGBqx/yCPSNJ83MNBdJd0Bz3WJT7v nobhSRsVBovMby7WI6T8KBURLhU5a68ZmNHn4pK7bRz7t/Ln5VvKmgSnClqke08Xx1rLE5tG2gO 9hHMPPGeGikXY6vMygNbigXg1A2H9pPA+sIPhn43TWAkfFqKmw0esbRIaAyOpnt4BsEKx9Qs= X-Gm-Gg: ASbGncvWxsKh1bDc8m/+aeWRcEuwCMZkfPNH+CNDsz4jd1ycenbrbcTGt2kjtBtYsSU ggJPbO8QzjdDwPjEN5lPfL6etoeE2Z5OKGMitOkQIiki62tu4H4Jau3dE0dnYY0zxYadYX9RKGx AUPFV5B1QNbO6yUNXoobHkyG1bkRPY3tiu5uDIgdM49snnWaTWqQFw3AZEQccKhwW+kLX3pcWAL af4+vAIjR2gzrnmPv1Vj0jRy7d8nuJgZxsUsl6/iXRquDppodnTfQWwRfclrjSZGqd74JcRaNsJ hNdOC7vVv0IxsxIQ51Oe1xchQkq59M6nbMw+iXx9+V0wongHw5VxGQDT4L/xALOF1m57Ow/4vAt K49b3 X-Received: by 2002:a05:6000:1a8e:b0:42b:3e0a:64b8 with SMTP id ffacd0b85a97d-42b593505bamr15137321f8f.24.1763472727019; Tue, 18 Nov 2025 05:32:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IFvboPh8q3apRPbs5zCU+bsRArBd39ikUSOopc28N3Wc1lH99PYEJcOtSuseNPH5p7ujVffQg== X-Received: by 2002:a05:6000:1a8e:b0:42b:3e0a:64b8 with SMTP id ffacd0b85a97d-42b593505bamr15137287f8f.24.1763472726544; Tue, 18 Nov 2025 05:32:06 -0800 (PST) Received: from localhost ([31.111.84.207]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42b53f0b8a0sm32827715f8f.25.2025.11.18.05.32.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Nov 2025 05:32:05 -0800 (PST) From: Andrew Burgess To: Simon Marchi , Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 1/6] gdb/testsuite/dwarf: use single abbrev table in .dwo files In-Reply-To: References: <20251107211041.520697-1-simon.marchi@efficios.com> <20251107211041.520697-2-simon.marchi@efficios.com> Date: Tue, 18 Nov 2025 13:32:04 +0000 Message-ID: <878qg3v54b.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: znh4gbS2i1g2KfOhuFjKsYUvMEecmvqPdi2rs9yh8Nk_1763472727 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Simon Marchi writes: > 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: I cannot parse the "which is even the DWO file is even generated" part here. Can you reword this? > > - 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 Not critical, but I think s/ran/run/ would be better. Thanks, Andrew > > 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