From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 9i9nEQraaWodEDMAWB0awg (envelope-from ) for ; Wed, 29 Jul 2026 06:46:34 -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=n8SdwvSe; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=1mKOR48O; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=GPTtYfXL; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=0OvDqBvN; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 25F801E09E; Wed, 29 Jul 2026 06:46:34 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.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 autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 4DF3C1E099 for ; Wed, 29 Jul 2026 06:46:31 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 56CBF4BB3BD5 for ; Wed, 29 Jul 2026 10:46:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 56CBF4BB3BD5 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=n8SdwvSe; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=1mKOR48O; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=GPTtYfXL; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=0OvDqBvN 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 BF4E34BA9000 for ; Wed, 29 Jul 2026 10:45:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF4E34BA9000 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 BF4E34BA9000 Authentication-Results: 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=1785321957; cv=none; b=GY4ek1Dv4Rpst7ZSyUxwUmBR8ToWuOyXSb+jbAkfSejA9HJKnvcuS9HiN95MQgM+xb2oh136b/fTTkiodSPhFN24t5j1KaEupJsTKNqPPM/Ffbq2BnP8o2e7VEsJxy7cUWyo1r/VUZZ87FZQV7dzXiGO4ZSP/ERGzvAccHNspDM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785321957; c=relaxed/simple; bh=Q8GZ9EhV/28Rdk0bZrjdEawhPjySfV9f/9g8oQZD/Zs=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:From: To:Subject:Date:Message-ID:MIME-Version; b=K/x0gZTS31vW/A3ocxRKunYIPDpn2naIlVgIYXDsGTV/YenY+atsk5b2xF1kc/UetvtAxiEZqG+d6unp4Cl+UfLeuV/x4KA0/56QANgHB7QZ7/yscm5GFzEMMlBRdpbhcLv5WWCZCSCzTp/EK3bYtV8Zy/ioPSPICtwOpRfBnz0= ARC-Authentication-Results: i=1; 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=n8SdwvSe; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=1mKOR48O; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=GPTtYfXL; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=0OvDqBvN DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF4E34BA9000 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104: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 7CA667B55F for ; Wed, 29 Jul 2026 10:45:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1785321951; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=g5VCaVqFErv8xBHmomp2vdXaETvX5kl/M82LsdoqeH8=; b=n8SdwvSeLpRSUVVychfxhy6QnU97vv030hJsmhF/AIYm/klEq7ExsiHDXj5t7C4YLQ47XH zq68h2QIfMVGY0VSU20KTWWsXdWNiWJ4M3P/BV1llwLJZb2A3M0YPJrQ2k2SoxnBzHRQlD 5b3Y48tb2Bl9jQ75B40sElX+nCeCxXo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1785321951; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=g5VCaVqFErv8xBHmomp2vdXaETvX5kl/M82LsdoqeH8=; b=1mKOR48OPXeGmErSPD0Xu3MkjDKPNw3xQbGOye0sDYklN9AN9lGiWqmACzar2wZAH6t2d5 +BvHAnRs+6Xj86DA== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=GPTtYfXL; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=0OvDqBvN DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1785321947; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=g5VCaVqFErv8xBHmomp2vdXaETvX5kl/M82LsdoqeH8=; b=GPTtYfXLY0wli91CZS7xopztuhjl/UDfsmDDhDiOLTmsQUTqwP3TGS8wO8pBahH5sxALGx 7Ma6fqoSIUcY47CwHZywgpcUqYwsbRKlh8Yb+jpMVPPZ7fNt/4JanQGaBWhGBHEwKEtf3G 5Aghgrz7k0tp02N8wpUgHfGnEYE/K9A= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1785321947; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=g5VCaVqFErv8xBHmomp2vdXaETvX5kl/M82LsdoqeH8=; b=0OvDqBvN1n4cQyKO2rqQXS69kmT2+CwYI80Ew+aQr7h62UeYCe7KS/eChqcXH5DpSpmQfp AZtV9Cvn1XFYEtAg== 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 671BC779A1 for ; Wed, 29 Jul 2026 10:45:47 +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 qgrOF9vZaWqXVgAAD6G6ig (envelope-from ) for ; Wed, 29 Jul 2026 10:45:47 +0000 From: Tom de Vries To: gdb-patches@sourceware.org Subject: [PATCH] [gdb/testsuite] Fix gdb.mi/mi-dlmopen.exp Date: Wed, 29 Jul 2026 12:45:46 +0200 Message-ID: <20260729104546.3108523-1-tdevries@suse.de> X-Mailer: git-send-email 2.51.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[gdb-patches@sourceware.org]; FROM_EQ_ENVFROM(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.de:mid,suse.de:dkim,sourceware.org:url]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; RCVD_TLS_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; DKIM_TRACE(0.00)[suse.de:+] X-Rspamd-Queue-Id: 7CA667B55F X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action 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 x86_64-linux (using glibc 2.40), in test-case gdb.mi/mi-dlmopen.exp we end up with 3 instances of the dynamic loader /lib64/ld-linux-x86-64.so.2: ... &"info sharedlibrary\n" ~"From To Linker Syms Shared Object Library\n" NS Read ~"0x00007ffff7fc8000 0x00007ffff7fff000 0 Yes ... ... ~"0x00007ffff7fc8000 0x00007ffff7fff000 1 Yes ... ... ~"0x00007ffff7fc8000 0x00007ffff7fff000 2 Yes ... ... and all 3 instances sharing the same mapping. Two subsequent unload events: ... =library-unloaded, id="/lib64/ld-linux-x86-64.so.2", target-name="/lib64/ld-linux-x86-64.so.2", host-name="/lib64/ld-linux-x86-64.so.2", thread-group="i1", ranges=[{from="0x00007ffff7fc8000",to="0x00007ffff7fff000"}], still-in-use="true" =library-unloaded, id="/lib64/ld-linux-x86-64.so.2", target-name="/lib64/ld-linux-x86-64.so.2", host-name="/lib64/ld-linux-x86-64.so.2", thread-group="i1", ranges=[{from="0x00007ffff7fc8000",to="0x00007ffff7fff000"}], still-in-use="true" ... report still-in-use as true. And that's correct: - after the first unload, the mapping is still in use by two instances - after the second unload, the mapping is still in use by one instance On ppc64le-linux (using glibc 2.34), I have instead for dynamic linker /lib64/ld64.so.2: ... &"info sharedlibrary\n" ~"From To Linker Syms Shared Object Library\n" NS Read ~"0x00007ffff7f80000 0x00007ffff8000000 0 Yes ... ~"0x0000000000000160 0xffffffffffff0000 1 Yes ... ~"0x0000000000000160 0xffffffffffff0000 2 Yes ... ... only 2 instances of the same mapping. The mapping looks suspiciously large to me, perhaps this is a bug in glibc. I didn't run into this problem with two other ppc64le-linux setups, with glibc versions 2.40 and 2.38. But I haven't tracked it down, so I can't rule out the possibility that there's a gdb problem. Regardless, the still-in-use values: ... =library-unloaded, id="/lib64/ld64.so.2", target-name="/lib64/ld64.so.2", host-name="/lib64/ld64.so.2", thread-group="i1", ranges=[{from="0x0000000000000160",to="0xffffffffffff0000"}], still-in-use="true" =library-unloaded, id="/lib64/ld64.so.2", target-name="/lib64/ld64.so.2", host-name="/lib64/ld64.so.2", thread-group="i1", ranges=[{from="0x0000000000000160",to="0xffffffffffff0000"}], still-in-use="false" ... look as expected to me: - after the first unload, the mapping is still in use by one instance - after the second unload, the mapping is no longer in use However, the test-case produces: ... FAIL: gdb.mi/mi-dlmopen.exp: still-in-use fields were all correct ... because it expects still-in-use == true for both unloads. Fix this by distinguishing between the two cases: - all mappings are the same: expect still-in-use == true - otherwise: allowing either true or false for still-in-use. For the second case, we could try to keep track of how many instances a range has, and predict the precise value of still-in-use based on that, but I'm not sure it's worth the effort for what looks like a corner-case. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33662 --- gdb/testsuite/gdb.mi/mi-dlmopen.exp | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.mi/mi-dlmopen.exp b/gdb/testsuite/gdb.mi/mi-dlmopen.exp index ff854ac7dd4..729a37eae28 100644 --- a/gdb/testsuite/gdb.mi/mi-dlmopen.exp +++ b/gdb/testsuite/gdb.mi/mi-dlmopen.exp @@ -162,6 +162,7 @@ proc check_solib_unload_events {} { # Check that the dynamic linker has now been loaded multiple times. set dyld_info [get_dyld_info] set dyld_count [lindex $dyld_info 0] + set dyld_start_addr [lindex $dyld_info 1] if { $dyld_count < 2 } { unsupported "not enough instances of the dynamic linker are mapped in" return @@ -185,7 +186,32 @@ proc check_solib_unload_events {} { if {[is_dyln $lib]} { # This is the dynamic linker being unloaded. incr dyld_unload_count - set expected_in_use "true" + + if {$dyld_start_addr != ""} { + # In this case (x86_64-linux, glibc 2.40): + # From To Linker NS + # 0x00007ffff7fc8000 0x00007ffff7fff000 0 + # 0x00007ffff7fc8000 0x00007ffff7fff000 1 + # 0x00007ffff7fc8000 0x00007ffff7fff000 2 + # the three instances are mapped at the same position, and + # after two unloads the mapping is still in use, so we + # expect true for both unloads. + set expected_in_use true + } else { + # And in this case (ppc64le-linux, glibc 2.34): + # From To Linker NS + # 0x00007ffff7f80000 0x00007ffff8000000 0 + # 0x0000000000000160 0xffffffffffff0000 1 + # 0x0000000000000160 0xffffffffffff0000 2 + # two instances are mapped at the same position, and after + # the first unload it's still in use, but not after the + # second one. + # We could add instances per mapping tracking to predict + # still-in-use for each unload, but it doesn't seem to be + # worth the trouble for this cornercase. So just accept + # whatever value was produced. + set expected_in_use $in_use + } } else { set expected_in_use "false" } base-commit: cd02e2a209482dd9fa06945ffec0675da7dfd74e -- 2.51.0