From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SYwuAj4IsmiSiQ8AWB0awg (envelope-from ) for ; Fri, 29 Aug 2025 16:06:22 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=default header.b=mK0IW5HO; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E97701E04C; Fri, 29 Aug 2025 16:06:21 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no 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 278DB1E023 for ; Fri, 29 Aug 2025 16:06:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B67483858409 for ; Fri, 29 Aug 2025 20:06:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B67483858409 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=default header.b=mK0IW5HO Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id C17613858C98 for ; Fri, 29 Aug 2025 20:05:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C17613858C98 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 C17613858C98 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=1756497946; cv=none; b=o0ufrRNofiQEVONNVmy20+hkP7u+TKiMRViV4kskxvpw1MyjuoTNPXAK/UwCkLNR0BjrmumNH4oeixXcLW/Br6lzy7f/AQzNMthGFbe+rV4Dj8u1xO2ebXUpHNC+T0Xtlj5G4FvKc1ktd5CvhQzjO+f+pYvdiB/6iR6TEsf16OA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756497946; c=relaxed/simple; bh=DWNeizRzNOAooimQ8F1oX2PPUxk7JrHMZwd/ei6ieeY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=s2y6YObdunGIZWL4LmHT2wyN3cHuMY9rBsxFHOZ81NxK0kK057B9wsf5c/i49cPBqtpVmldUhCHhzzxteH/xhZca4xkO9SX7aRUNqffM8ND7K+mRNl4JI11HyQEkEGCAhq4NUYOaK7dYGCATId/wo9waDCGI0UJ9nZbHGm0+Ayk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C17613858C98 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 57TK5eMV139136 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Aug 2025 16:05:44 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 57TK5eMV139136 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1756497945; bh=FPevK0Y0EUNedA5HADoNd0kJP9gRNrwSejscRSEfNKs=; h=From:To:Cc:Subject:Date:From; b=mK0IW5HOpaIR5lpgR+ZlJQSXSulwvXqykNPwG2XRUqlaUgAtk0xwsy/d892oZXLaD YJSM9Z0UP2ccePqQocp6wa7Tmt8Q23gNHVrZ7PzTCUe3tH/rwifbphzn41zd4UoDkM HehOngk+GJ55bnmUmtlQd0MV4Rvnb69PDYnHkIj0= Received: by simark.ca (Postfix) id 006D21E023; Fri, 29 Aug 2025 16:05:39 -0400 (EDT) From: simon.marchi@polymtl.ca To: gdb-patches@sourceware.org Cc: Simon Marchi Subject: [PATCH][fix the buildbot] gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos Date: Fri, 29 Aug 2025 16:05:27 -0400 Message-ID: <20250829200538.2276767-1-simon.marchi@polymtl.ca> X-Mailer: git-send-email 2.50.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 29 Aug 2025 20:05:40 +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 From: Simon Marchi Commit d33a66a31134 ("gdb/solib-svr4: fix wrong namespace id for dynamic linker") regressed test gdb.base/break-probes.exp with the native-gdbserver board: Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/break-probes.exp ... FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited) FAIL: gdb.base/break-probes.exp: call (int) foo(23) In the logs, we see this: Stopped due to shared library event: Inferior unloaded target:/lib64/ld-linux-x86-64.so.2 Inferior loaded target:/lib64/ld-linux-x86-64.so.2 When we should see this: Stopped due to shared library event (no libraries added or removed) In the unexpected output, GDB claims that the inferior unloaded and then loaded the dynamic linker. This is obviously not true. Commit d33a66a31134 changed the svr4_same function to consider the debug bases the solibs come from. Two solibs with the same inferior address but different debug base (such as the multiple solibs representing the dynamic linker in all the namespaces) now compare unequal. That commit also introduced a mechanism to update the debug base of an existing solib (more precisely, field lm_info_svr4::debug_base) when that value becomes known. The solib for the dynamic linker view in the default namespace starts with a debug base of 0, and is then changed to have the real debug base address later on. With the particular code path taken when connecting to a remote target, nothing triggers the update of the debug base of the dynamic linker solib initially created with a debug base of 0. So when svr4_solib_ops::current_sos returns a list with an solib for the dynamic linker with the real debug base value, the core sees this as an unload and a load. This happens specifically when debuggin remotely, because, svr4_solib_ops::current_sos_direct takes the "using_xfer" branch, which doesn't do any svr4_solib_ops::default_debug_base call. In local, we don't take that branch, which leads us to a call to default_debug_base. The way I propose to fix it is to add a call to svr4_solib_ops::default_debug_base at the beginning of svr4_solib_ops::current_sos. The rationale to put it there is that if the core is requesting a fresh list of libraries, and then compare that list with what it had previously, then we better make sure that the core's list has received the debug base update, if one is needed. Change-Id: If09c5a7b3d956e18d4b9514466226267c85f12a6 --- gdb/solib-svr4.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c index 635e52a19877..58432b69a5d5 100644 --- a/gdb/solib-svr4.c +++ b/gdb/solib-svr4.c @@ -1512,6 +1512,15 @@ owning_intrusive_list svr4_solib_ops::current_sos () const { svr4_info *info = get_svr4_info (current_program_space); + + /* Call this for the side-effect of updating the debug base in existing + solibs' lm_info_svr4, if needed. It is possible for the core to have + an solib with a stale lm_info_svr4::debug_base. In that case, we are + about to return the same solib, but with an updated debug_base. If we + didn't do this call, then it would appear as two different libraries to + the core, and it would appear as a spurious unload / load. */ + this->default_debug_base (info); + owning_intrusive_list sos = this->current_sos_1 (info); struct mem_range vsyscall_range; base-commit: 7a8821ff0e1badeaa284f6a6ff0b79b8e1fe5237 -- 2.50.1