From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UQ9UJbHUHWka1hMAWB0awg (envelope-from ) for ; Wed, 19 Nov 2025 09:31:13 -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=Is4MOms9; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 817171E0B6; Wed, 19 Nov 2025 09:31:13 -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=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 B72C01E048 for ; Wed, 19 Nov 2025 09:31:11 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 25DCD385275F for ; Wed, 19 Nov 2025 14:31:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 25DCD385275F 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=Is4MOms9 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 890033858C41 for ; Wed, 19 Nov 2025 14:30:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 890033858C41 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 890033858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763562611; cv=none; b=JjGTq6pfyqNpo+wR0cZZglS64avS8CvaZLj9CLbIipCyx9/eB5drltV2st3pqs/50fy50fyOMNBWGMVayl0RSxwyvMEYaK7fCwBqMkZC45QcxCxiP46xBf2gX0u+hiAD50h1a8NPeewkoweYXgKuO7aHZplNqDuN0/Y1/9AIywc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763562611; c=relaxed/simple; bh=DRWBIcgaqrhIZsIHwHeaIp+YdqcaidImb0yg8u+IKPo=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ZhSP7smd4PRput3tVlOuVF53xb+t1otIZn7iNYtHBvcL/cSoLnZyQJoEbq6gNx1aoGXS2vYvjYRaq7JP0uToToICQ7f33Cuu7fYRR1NZYKAFQT36JqBmeURsIw5KPxcWfI1LO8BM70z/W2J/l79GTM34bpZRRiOIjMNwmFyWVcg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 890033858C41 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763562611; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PEmcUMgu8x6NlBwmqMTY2ctqJNBew86m4ZebYxwQqAs=; b=Is4MOms9uMpSZFaCLAzfzow/2ZKaJcHjR+RmSptq7nerCnieM5BUkYOICSItAZN+E3Einq S7/NKYhY91xxCt5iJhlG3FT+4zK8GQl3XvGpl7tJmmtoe3J7Heg+3b+MMAogyljrXWSZfU pMaz2MSJEM0tw1owQOh3KAXvTIcvIc8= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-472-BDsnCFwyMniGriFbX1GdwQ-1; Wed, 19 Nov 2025 09:30:10 -0500 X-MC-Unique: BDsnCFwyMniGriFbX1GdwQ-1 X-Mimecast-MFC-AGG-ID: BDsnCFwyMniGriFbX1GdwQ_1763562609 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4779c35a66bso28331445e9.2 for ; Wed, 19 Nov 2025 06:30:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763562608; x=1764167408; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PEmcUMgu8x6NlBwmqMTY2ctqJNBew86m4ZebYxwQqAs=; b=EVAqUL2WJ2dhhz0foMG+C9CzU03ASiAfu+BcqrwFXm7k5DVJ9irOLzO1jE2K/tItrR vdToxa+H8oZN19iLuwtAMfHlyicyO0H4MD92P4HUayDqes4caf2fltfg7OihMCVtwKk/ Wp3SuqNnWekH1eHQ1wCBt17nS3D9FWCCXczKJkUbQNrYuPAeRJjRBPeTTFaz5e/RZNVP 4v9XVqhwCGgB+hplwAjsvkyu+W6qJFLOv/lX1J/QFvdBHnC31rG8SUcPGQe4Wn9nb0aN lV7ZF+uMK/6uczKG4btLYjOhdTGjqTPWxpvg5PUZVypYAyUaEG0SlqPNb6F7VGRui7sF 8iug== X-Forwarded-Encrypted: i=1; AJvYcCX7R98fIjwu7dPr/Wk1ZkSYHFfBE/P5C+iImq7XYyflVKcWN0m+NO8RntsnrSUOu2Bc7xgBz73L1h7fJA==@sourceware.org X-Gm-Message-State: AOJu0YwpayNGDsLu/jcdOJ770DGuDn8YjCsntODgwzu9Wges9VU8QUFl sEc7WyLAKCPhE4zfc1GHxO4j880Ffi8oRMdXMCgHV80bkmlUh0G64aAUQHAD7GJg8bH/NsJlc0Y 3ela4cMrI0sqJgUojlZGOqTvUPspw8gF4OqVk03fRafNKzBeimAWzGox4B3teJ/T/bDhW9ao= X-Gm-Gg: ASbGncsQDDdpxKYsEHNTeSCBaWPx/eS40D2FPxqrwXO2sszea+ie5bL0scckxJVUrv1 BWRPXVXNamiCU19RnFk7LuGTZ4q8HpoLr6dbC+LCs1qMPCI/dVaMKnNWO2TA4CjDKqL7bHnNxqB V14DyD+SCbcN4KLzst+Rm6GDrqk22RZbBbJ9cYc2mHAsFVtLdPUbpYkwHKXod/43fdE55H5CV98 Wh34TFkx23RxhqDJ5Qi5Wwzq2Z+nIozT6zQcpT6/DHKSsqjyxrlhbvUhG7UxE9fIZJYejEWqGUf BOv/bnGF9pggq74wDQDWsndWjlKxaCWSPAICv4xL6vFrSqiDE7363vXLuOYnkespf2mg3+OvgSR 0UPMY X-Received: by 2002:a05:600c:3104:b0:477:7f4a:44b0 with SMTP id 5b1f17b1804b1-4778fe89527mr205140805e9.33.1763562608304; Wed, 19 Nov 2025 06:30:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IGcQeE4ajvGEsL69A52fHMvcKPrjlrwi/iZKOzpKnyg+u8hiAZMmMzD57E+PTRHhf3lOwUE0g== X-Received: by 2002:a05:600c:3104:b0:477:7f4a:44b0 with SMTP id 5b1f17b1804b1-4778fe89527mr205140335e9.33.1763562607700; Wed, 19 Nov 2025 06:30:07 -0800 (PST) Received: from localhost ([31.111.84.207]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-477b103d312sm63334855e9.13.2025.11.19.06.30.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Nov 2025 06:30:07 -0800 (PST) From: Andrew Burgess To: Simon Marchi , gdb-patches@sourceware.org Cc: Simon Marchi Subject: Re: [PATCH 4/6] gdb/dwarf: when in dwarf2_cu, read addr_size from dwarf2_cu::header In-Reply-To: <20251107211041.520697-5-simon.marchi@efficios.com> References: <20251107211041.520697-1-simon.marchi@efficios.com> <20251107211041.520697-5-simon.marchi@efficios.com> Date: Wed, 19 Nov 2025 14:30:06 +0000 Message-ID: <87jyzmt7rl.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: a0vINHHxGlQgOI4FWFEE_1yLJepurNEVgtPhv7woCcs_1763562609 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: > This patch fixes a crash caused by GDB trying to read from a section not > read in. The bug happens in those specific circumstances: > > - reading a type unit from .dwo > - that type unit has a stub in the main file > - there is a GDB index (.gdb_index) present > > This crash is the cause of the following test failure: > > $ Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/fission-reread.exp ... > ERROR: GDB process no longer exists It's probably worth mentioning that this failure only occurs when using the cc-with-gdb-index board. > > Or, manually: > > $ ./gdb -nx -q --data-directory=data-directory /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-reread/fission-reread -ex "p 1" > Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-reread/fission-reread... > > Fatal signal: Segmentation fault > > For this last one, you need to interrupt the test (e.g. add a return) > before the test deletes the .dwo file. > > The backtrace at the moment of the crash is: > > #0 0x0000555566968f7f in bfd_getl32 (p=0x0) at /home/simark/src/binutils-gdb/bfd/libbfd.c:846 > #1 0x00005555642e561d in read_initial_length (abfd=0x7d1ff1eb0e40, buf=0x0, bytes_read=0x7bfff0962fa0, handle_nonstd=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/leb.c:92 > #2 0x00005555647ca9ea in read_unit_head (header=0x7d0ff1e068b0, info_ptr=0x0, section=0x7c3ff1dea7d0, section_kind=ruh_kind::COMPILE) at /home/simark/src/binutils-gdb/gdb/dwarf2/unit-head.c:44 > #3 0x000055556452e37e in dwarf2_per_cu::get_header (this=0x7d0ff1e06880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18531 > #4 0x000055556452e574 in dwarf2_per_cu::addr_size (this=0x7d0ff1e06880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18544 > #5 0x000055556406af91 in dwarf2_cu::addr_type (this=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/cu.c:124 > #6 0x0000555564534e48 in set_die_type (die=0x7e0ff1f23dd0, type=0x7e0ff1f027f0, cu=0x7d7ff1e20880, skip_data_location=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:19020 > #7 0x00005555644dcc7b in read_structure_type (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11239 > #8 0x000055556451c834 in read_type_die_1 (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16878 > #9 0x000055556451c5e0 in read_type_die (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16861 > #10 0x0000555564526f3a in get_signatured_type (die=0x7e0ff1f0ffb0, signature=10386129560629316377, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:17998 > #11 0x000055556451c23b in lookup_die_type (die=0x7e0ff1f0ffb0, attr=0x7e0ff1f10008, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16808 > #12 0x000055556451b2e9 in die_type (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16684 > #13 0x000055556451457f in new_symbol (die=0x7e0ff1f0ffb0, type=0x0, cu=0x7d7ff1e0f480, space=0x0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16089 > #14 0x00005555644c52a4 in read_variable (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9119 > #15 0x0000555564494072 in process_die (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:5197 > #16 0x000055556449c88e in read_file_scope (die=0x7e0ff1f0fdd0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:6125 > #17 0x0000555564493671 in process_die (die=0x7e0ff1f0fdd0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:5098 > #18 0x00005555644912f5 in process_full_comp_unit (cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:4851 > #19 0x0000555564485e18 in process_queue (per_objfile=0x7d6ff1e71100) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:4161 > #20 0x000055556446391d in dw2_do_instantiate_symtab (per_cu=0x7ceff1de42d0, per_objfile=0x7d6ff1e71100, skip_partial=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1650 > #21 0x0000555564463b3c in dw2_instantiate_symtab (per_cu=0x7ceff1de42d0, per_objfile=0x7d6ff1e71100, skip_partial=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1671 > #22 0x00005555644687fd in dwarf2_base_index_functions::expand_all_symtabs (this=0x7c1ff1e04990, objfile=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1990 > #23 0x0000555564381050 in cooked_index_functions::expand_all_symtabs (this=0x7c1ff1e04990, objfile=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/dwarf2/cooked-index.h:237 > #24 0x0000555565df5b0d in objfile::expand_all_symtabs (this=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/symfile-debug.c:372 > #25 0x0000555565eafc4a in maintenance_expand_symtabs (args=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/symmisc.c:914 > > The main file contains a stub (skeleton) for a compilation unit and a > stub for a type unit. The .dwo file contains a compilation unit and a > type unit matching those stubs. When doing the initial scan of the main > file, the DWARF reader parses the CU/TU list from the GDB index > (.gdb_index), and thus creates a signatured_type object based on that. > The section field of this signatured_type points to the .debug_types > section in the main file, the one containing the stub. And because GDB > trusts the GDB index, it never needs to look at that .debug_types > section in the main file. That section remains not read in. > > When expanding the compilation unit, GDB encounters a type unit > reference (by signature) corresponding to the type in the type unit. We > get in lookup_dwo_signatured_type, trying to see if there is a type unit > matching that signature in the current .dwo file. We proceed to read > and expand that type unit, until we eventually get to a > dwarf2_cu::addr_type() call, which doess: > > int addr_size = this->per_cu->addr_size (); > > dwarf2_per_cu::addr_size() tries to read the header from the section > pointed to by dwarf2_per_cu::section which, if you recall, is the > .debug_types section in the main file that was never read in. That > causes the segfault. > > All this was working fine before these patches of mine, that tried to do > some cleanups: > > a47e2297fc28 ("gdb/dwarf: pass section offset to dwarf2_per_cu_data constructor") > c44ab627b021 ("gdb/dwarf: pass section to dwarf2_per_cu_data constructor") > 39ee8c928551 ("gdb/dwarf: pass unit length to dwarf2_per_cu_data constructor") > > Before these patches, the fill_in_sig_entry_from_dwo_entry function > (called from lookup_dwo_signatured_type, among others) would overwrite > some dwarf2_per_cu fields (including the section) to point to the .dwo, > rather than represent what's in the main file. Therefore, the header > would have been read from the unit in the .dwo file, and things would > have been fine. > > When doing these changes, I mistakenly assumed that the section written > by fill_in_sig_entry_from_dwo_entry was the same as the section already > there, which is why I removed the statements overwriting the section > field (and the two others). To my defense, here's the comment on > dwarf2_per_cu::section: > > /* The section this CU/TU lives in. > If the DIE refers to a DWO file, this is always the original die, > not the DWO file. */ > struct dwarf2_section_info *section = nullptr; > > I would prefer to not reintroduce the behavior of overwriting the > section info in dwarf2_per_cu, because: > > 1. I find it confusing, I like the invariant of dwarf2_per_cu::section > points to the stub, and dwarf2_cu::section points to where we > actually read the debug info from. > 2. The dwarf2_per_bfd::all_units vector is nowadays sorted by (section, > section offset). If we change the section and section offset of a > dwarf2_per_cu, then we can no longer do binary searches in it, we > would have to re-sort the vector (not a big deal, but still adds to > the confusion). > > One possible fix would be to make sure that the section is read in when > reading the header, probably in dwarf2_per_cu::get_header. An approach > like that was proposed by Andrew initially, here: > > https://inbox.sourceware.org/gdb-patches/60ba2b019930fd6164f8e6ab6cb2e396c32c6ac2.1759486109.git.aburgess@redhat.com/ > > It would work, but there is a more straightforward fix for this > particular problem, I believe. In dwarf2_cu, we have access to the > header read from the unit we're actually reading the DWARF from. In the > DWO case, that is the header read from the .dwo file. We can get the > address size from there instead of going through the dwarf2_per_cu > object. This is what this patch does. This looks good to me. I would encourage you to consider extending the existing test to cover this case without needing to test with the cc-with-gdb-index board. I think the reality is most people don't test every patch with every board. But I do understand that, if taken to extreme, that would mean running every test in every mode, which clearly doesn't scale. But when we run into a regression my instinct is to ensure that the default test mode covers this case. And there's plenty of precedent for this in the testsuite, e.g. gdb.server/*.exp. You're welcome to take the test changes from the patch linked above if that is useful. Also in the patch linked above is the addition of an assert: gdb_assert (this->section ()->readin); in 'dwarf2_per_cu::get_header ()'. I haven't checked the later patches from this series yet, so maybe you already do something similar, but if not, maybe it would be good to add something like that in this patch, given that this is dealing with the assert caused by the section not being read in? Anyway, these aren't hard requirements, just my thoughts. I think the fix looks good. Approved-By: Andrew Burgess Thanks, Andrew