From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id H4b6ER1F1mkRbA0AWB0awg (envelope-from ) for ; Wed, 08 Apr 2026 08:07:57 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=bmzciXGN; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=+As3w3lQ; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=bmzciXGN; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=+As3w3lQ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2FDF91E04F; Wed, 08 Apr 2026 08:07:57 -0400 (EDT) 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 vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 B4D621E04F for ; Wed, 08 Apr 2026 08:07:55 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 522994BA2E1B for ; Wed, 8 Apr 2026 12:07:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 522994BA2E1B Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=bmzciXGN; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=+As3w3lQ; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=bmzciXGN; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=+As3w3lQ Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by sourceware.org (Postfix) with ESMTPS id 743214BA2E08 for ; Wed, 8 Apr 2026 12:07:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 743214BA2E08 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 743214BA2E08 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1775650048; cv=none; b=Wnj37WeDuoYnfiV1rNTjd3RvL+jvbja0LIU6KHEeo39jNxIDmilW4bS769acOnTPxBDtVcb90aPXnCvkTH/FcLpoIti05JtDPrCwynA4CDrik9qtv3yMpk22dctVZ5XrrU3V7pyGuPgiu7QBJnumDI0vQRjGc9g1tvyLfo8B1OI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1775650048; c=relaxed/simple; bh=VmtjrfW/RAZU8qRXt9kp7qC1w970G/8tOaVKvxKJQRI=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:From:To; b=icuvNHH6Yuj8egJAPXnFQf1ldRvKYozLv8jXWNEsPoxtmF6jWQyUp4hfFx77F93LV5IE24oQ+t2XPggNGpqx5N79x4nV/5B8jA2P58bvAzvwTCnfirX6EorVGVu3XGZvBRjPLUmq+UfPzgPQJGdpuA7Xg5kCP2nwuMPUxNwfc2k= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 743214BA2E08 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 640884E9A1 for ; Wed, 8 Apr 2026 12:07:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1775650047; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FDC47k7BsXox+3M1yI1s+ALoiDzwDgRApFZTQXroBZo=; b=bmzciXGNiuV6741GnSEtQV9Jo4oIxID8nqpoqY8Xqr/ZtGas3LFqu2PC+H2DMIGgE+rdqa x+cApXiNPEf8bOHUpH2Q4tee8kv2BELsxYNntZnB4p7r8QxXLQkiWR0WfYGzD23J7JgH08 z7mezzlrJxdaTIQdBkaAsAiByR42jMs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1775650047; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FDC47k7BsXox+3M1yI1s+ALoiDzwDgRApFZTQXroBZo=; b=+As3w3lQA0qBoE5GQR6CoxC3zDFQZR+d5IrONEh/lVOd5FxDus6604EyRzxF6uCIjiKZZ+ W6NdT+VKY/gqUmAw== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1775650047; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FDC47k7BsXox+3M1yI1s+ALoiDzwDgRApFZTQXroBZo=; b=bmzciXGNiuV6741GnSEtQV9Jo4oIxID8nqpoqY8Xqr/ZtGas3LFqu2PC+H2DMIGgE+rdqa x+cApXiNPEf8bOHUpH2Q4tee8kv2BELsxYNntZnB4p7r8QxXLQkiWR0WfYGzD23J7JgH08 z7mezzlrJxdaTIQdBkaAsAiByR42jMs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1775650047; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FDC47k7BsXox+3M1yI1s+ALoiDzwDgRApFZTQXroBZo=; b=+As3w3lQA0qBoE5GQR6CoxC3zDFQZR+d5IrONEh/lVOd5FxDus6604EyRzxF6uCIjiKZZ+ W6NdT+VKY/gqUmAw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 543E24A0B5 for ; Wed, 8 Apr 2026 12:07:27 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id SRioEv9E1mlnUgAAD6G6ig (envelope-from ) for ; Wed, 08 Apr 2026 12:07:27 +0000 Message-ID: Date: Wed, 8 Apr 2026 14:07:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 2/2] [gdb/symtab] Don't expand type units for breakpoints From: Tom de Vries To: gdb-patches@sourceware.org References: <20260408110827.2249311-1-tdevries@suse.de> <20260408110827.2249311-3-tdevries@suse.de> Content-Language: en-US In-Reply-To: <20260408110827.2249311-3-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[gdb-patches@sourceware.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:mid] 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 4/8/26 1:08 PM, Tom de Vries wrote: > Consider a cc1plus exec compiled with GCC and LTO [1]. > > If we try to set a breakpoint on do_rpo_vn: > ... > $ gdb -q -batch cc1plus \ > -ex "b do_rpo_vn" > Breakpoint 1 at 0xfd75f0: do_rpo_vn. (2 locations) > ... > we expand 435 units: > ... > $ gdb -q -batch cc1plus \ > -ex "b do_rpo_vn" \ > -ex "maint print statistics" \ > | grep "Number of read units" > Number of read units: 435 > ... > > [ When compiling with LTO, GCC generates debug info in two phases: > - in the early phase, it generates a unit for each source file, containing the > types in the source file. Let's call these type-only units. > - in the late phase, it generates a so-called artificial unit for each > optimized code blob. The artificial unit doesn't contains types, but > imports them from the type-only units. > > The cc1plus exec contains 1150 units, 128 of which are artificials units: > ... > $ readelf -wi --dwarf-depth=1 cc1plus | grep -c "Compilation Unit @" > 1150 > $ readelf -wi --dwarf-depth=1 cc1plus | grep -c "" > 128 > ... ] > > Most of the expanded units are type-only units, which have no relevant > information when we're looking for function symbols. > > They're merely expanded because the artificial units import them. > > So the question is: can we skip expanding the type-only units when looking for > function symbols? > > This patch contains a naive implementation of that approach, in process_queue. > > Using it, we expand just 7 artificial units: > ... > $ gdb -q -batch cc1plus \ > -ex "b do_rpo_vn" \ > -ex "maint print statistics" \ > | grep "Number of read units" > Number of read units: 7 > ... > > But there's a problem with this implementation, which we can illustrate using > DWZ: > ... > $ cat test.c > struct s { > int x0, x1, x2, x3, x4, x5, x6, x7, x8, x9; > }; > struct s var1; > int main (void) { > return 0; > } > $ gcc -g test.c; rm -f ab.dwz; cp a.out b.out; dwz -m ab.dwz a.out b.out > $ gdb -q -batch a.out -ex "b main" -ex "ptype struct s" > Breakpoint 1 at 0x40111a: file test.c, line 6. > No struct type named s. > ... > > First, we use DWZ to move struct s to a partial unit. > > Then in the GDB session the following happens: > - setting a breakpoint on main expands the test.c CU > - the test.c CU has an import of the partial CU, but the partial CU is not > expanded, because it contains only types > - printing struct s attempts to expand test.c CU, finds that it's already > expanded, and the partial CU containing struct s remains unexpanded. > - gdb tries to find struct s in the expanded CUs, and struct s is not found. > I tried bypassing this problem for DWZ using: ... @@ -3910,6 +3910,7 @@ process_queue (dwarf2_per_objfile *per_objfile, domain_search_flags domain) gdb_assert (!per_objfile->compunit_symtab_set_p (per_cu)); bool skip = (domain == SEARCH_FUNCTION_DOMAIN + && cu->header.unit_type != DW_UT_partial && !per_cu->addresses_seen); if (skip) { ... and that does fix the DWZ counter-example, but not the testsuite regressions mentioned below. IWBN though to have this work for partial units as well. > RFC: what is the best way to fix this problem? > > I wondered about expanding function compunit_symtab_set_p et al with a > domain_search_flags parameter, giving us a way to express that a CU is > expanded for SEARCH_FUNCTION_DOMAIN, but not for other domains. > > But there may be a better way to achieve this. > > [ FWIW, I've tested this on x86_64-linux, and ran into a number of FAILs: > ... > 9 gdb.cp/cpexprs-debug-types.exp: > 1 gdb.dlang/circular.exp: > 2 gdb.dwarf2/ada-cold-name.exp: > 4 gdb.dwarf2/ada-linkage-name.exp: > 14 gdb.dwarf2/dw2-bad-abstract-origin.exp: > 1 gdb.dwarf2/dw2-inline-bt.exp: > 1 gdb.dwarf2/dw2-prologue-end-2.exp: > 1 gdb.dwarf2/dw2-ranges-psym.exp: > 7 gdb.dwarf2/dw2-step-between-different-inline-functions.exp: > 6 gdb.dwarf2/dw2-step-between-inline-func-blocks.exp: > 60 gdb.dwarf2/dw2-unexpected-entry-pc.exp: > 1 gdb.dwarf2/inlined_subroutine-inheritance.exp: > 1 gdb.dwarf2/struct-decl.exp: > ... ] > I investigated the last failure. The problem is that addresses_seen is false in this CU: ... <0><2dc>: Abbrev Number: 1 (DW_TAG_compile_unit) <2dd> DW_AT_language : 4 (C++) <2de> DW_AT_name : main.c <2e5> DW_AT_comp_dir : /tmp <1><2ea>: Abbrev Number: 2 (DW_TAG_structure_type) <2eb> DW_AT_byte_size : 8 <2ec> DW_AT_encoding : 5 (signed) <2ed> DW_AT_name : the_type <2f6> DW_AT_declaration : 1 <2><2f6>: Abbrev Number: 3 (DW_TAG_subprogram) <2f7> DW_AT_name : method <2fe> DW_AT_declaration : 1 <2><2fe>: Abbrev Number: 0 <1><2ff>: Abbrev Number: 4 (DW_TAG_subprogram) <300> DW_AT_specification: <0x2f6> <304> DW_AT_low_pc : 0x401116 <30c> DW_AT_high_pc : 0x401121 <1><314>: Abbrev Number: 0 ... because the top-level DIE does not contain a PC range, despite the CU containing a subprogram with PC range. Thanks, - Tom > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33922 > --- > gdb/dwarf2/read.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index afd0b60006e..475dc03f0b0 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -1945,7 +1945,8 @@ dwarf2_base_index_functions::search_one > > compunit_symtab *symtab > = dw2_instantiate_symtab (per_cu, per_objfile, false, domain); > - gdb_assert (symtab != nullptr); > + if (symtab == nullptr) > + return true; > > if (listener != nullptr) > { > @@ -3908,6 +3909,15 @@ process_queue (dwarf2_per_objfile *per_objfile, domain_search_flags domain) > > gdb_assert (!per_objfile->compunit_symtab_set_p (per_cu)); > > + bool skip = (domain == SEARCH_FUNCTION_DOMAIN > + && !per_cu->addresses_seen); > + if (skip) > + { > + cu->queued = false; > + per_objfile->queue->pop (); > + continue; > + } > + > namespace chr = std::chrono; > > unsigned int debug_print_threshold;