From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YGZUHYLusmgmBxAAWB0awg (envelope-from ) for ; Sat, 30 Aug 2025 08:28:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1756556930; bh=fmVXYZGTuST92CDMBZ+aJL8Ou2GhTHlDAp4UgLL8rTc=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=T9nHxKdpf9GaJaOtMv+RjfXmxzjKejwHoikFflCT7Gi2qEBZnWN8X0cdKSCE+5/eJ 7lYr+WrZE3gAmcyMh0EFWBQiE2/K7gfe7xseMs/L26B4nF9Ks9E78nezpOBhI2yUUD xBcKR7P81iorZwsrDzolgchiTc7yZU9045xaZiU4= Received: by simark.ca (Postfix, from userid 112) id 5DBAD1E04C; Sat, 30 Aug 2025 08:28:50 -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 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=mvfmUjoD; dkim-atps=neutral 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 834271E043 for ; Sat, 30 Aug 2025 08:28:49 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F1E473858410 for ; Sat, 30 Aug 2025 12:28:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F1E473858410 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=mvfmUjoD Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C93D13858D37 for ; Sat, 30 Aug 2025 12:28:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C93D13858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C93D13858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756556894; cv=none; b=ZvS9YatTm6mPKHIAilZVWKgLNGPV+5TeyYzpeoSSi5ZWJrFXEuoTvPZzPYmPkwPYnr6C3bGg2TETSL1rF2vDb/gbsH95s5p+KCHQpFbPhykNil5F4yT1zSZqbvRKr8pR1Udnnk7OV+gAWehpZ+THX+bt0CEFuiX2UXYaV83tWdo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756556894; c=relaxed/simple; bh=fmVXYZGTuST92CDMBZ+aJL8Ou2GhTHlDAp4UgLL8rTc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=LabhvTZSRf+A4IL88iwVsdqNkOIPLT8d4vLBuZe31WXKM58mo/F6JWBDlyqig6qGt9vDC8ciI/GUS6yaABX978kcMopX7M5gy8UrAUaEJxI2rBiHufXa6sMb0BXbVuPBu8WBUyQe62UkQ5jLvgvHOIVelzi3Lpm601iy432j9d4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C93D13858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1756556894; bh=fmVXYZGTuST92CDMBZ+aJL8Ou2GhTHlDAp4UgLL8rTc=; h=Date:Subject:To:References:From:In-Reply-To:From; b=mvfmUjoDAyOF6IyVsFhesbEEeWUAzrF0DRmwKgDgxXGocgcVbYt3HEKT0AKGAQk3s 4xS03YXVxTj7CsxatDE5qsRh/9T0REYg26pkV7jPVt7tYoqfwdCr5X6c6ru0x1Ajzs VxCUlnSdzJOrEOkDhNdFpmiRUTu15c5IDF/i8PFg= Received: by simark.ca (Postfix) id 44BEC1E043; Sat, 30 Aug 2025 08:28:14 -0400 (EDT) Message-ID: <349ee584-b387-4f32-9ce4-4758d4f9c009@simark.ca> Date: Sat, 30 Aug 2025 08:28:13 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH][fix the buildbot] gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos To: Kevin Buettner , gdb-patches@sourceware.org References: <20250829200538.2276767-1-simon.marchi@polymtl.ca> <20250829205023.6aa24f0c@f41-zbm-amd> Content-Language: en-US From: Simon Marchi In-Reply-To: <20250829205023.6aa24f0c@f41-zbm-amd> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 2025-08-29 23:50, Kevin Buettner wrote: > On Fri, 29 Aug 2025 16:05:27 -0400 > simon.marchi@polymtl.ca wrote: > >> 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; >> > > LGTM. > > Approved-by: Kevin Buettner > Thanks, pushed. Simon