From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id N6SqCHRe2GeG9hIAWB0awg (envelope-from ) for ; Mon, 17 Mar 2025 13:40:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1742233204; bh=fVeszzclmbJoLoiC9icTGVTS1OQbCTnq46hP5BE8ERg=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=fPAbmRprQvAdb8si769wEt064YpRhtCFrdmP4G54spfyDYaDFAkChy7YmWZNqCKOg g8xf2Prs/Zsmc4d+9KFQ4MwLuNUCxoyel/R//LsaAxCvZlhujevL8l6mObYcWaKoVx OHWnQl253g2R+/99wHMOQmq0gFq1izh5z+VVGTcc= Received: by simark.ca (Postfix, from userid 112) id 110E11E100; Mon, 17 Mar 2025 13:40:04 -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=unavailable 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=QWd5+bPG; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=TTl/zCPC; 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 3984F1E0C0 for ; Mon, 17 Mar 2025 13:40:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 09427385AC20 for ; Mon, 17 Mar 2025 17:40:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 09427385AC20 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=QWd5+bPG; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=TTl/zCPC Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id DFC32385B804 for ; Mon, 17 Mar 2025 15:38:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DFC32385B804 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 DFC32385B804 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=1742225883; cv=none; b=feXi/EOn41hapTHnmKNASNb54BNXvlM6h0iwytncW36j1nrQxKa2R/Syk+u+nnCNU5dmJtK9sYKjgSHWpv2ijrXo0gJKWwBnkM4YuzKslbdtzsJs30yCV4D/KNMyRAzFWKK+nCsJAz2iaom7gmPyq0M2JVUtrnxr9viqVbX4FDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1742225883; c=relaxed/simple; bh=fVeszzclmbJoLoiC9icTGVTS1OQbCTnq46hP5BE8ERg=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=Yyli7wgb2YDU94WLJfL/8o3nsphYVq21oYdJ13Vfo/HDM80DzHBrCLgqdS1AAQRP8rW/cYjLP45VnDBO5a1jJu4vY1IHdOkMlT+B9SImAx3Fzn8TIDOffn1y7snfTSY9ZWzatX7hPZqpdogllqDVKGRJg58JVyZ9BLsGdSWu94g= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DFC32385B804 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1742225820; bh=fVeszzclmbJoLoiC9icTGVTS1OQbCTnq46hP5BE8ERg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=QWd5+bPGv/8YSrm8zpF8Izm2JgZCCtOf+yviXdo17KWDr+2ml1UZri6EI7X7nvT4r V9urR0wyeO49x5LFWWpedwbAnfieqrp1QnIW1WDpURFTZrPfYRlZJNngEgQR5JfUCP NChQXrE7HX4GAMEmfCLTGqMQHY3RNIa1LKS7WjTw= Received: by simark.ca (Postfix, from userid 112) id A403C1E11B; Mon, 17 Mar 2025 11:37:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1742225819; bh=fVeszzclmbJoLoiC9icTGVTS1OQbCTnq46hP5BE8ERg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=TTl/zCPCdcjrOsGpE56jSlh2N2tQU4NXfrc3GWyJY0Flg23L72HYWv72aWHKRcPas b7iNn0Pyy4BEJ5/U42wK+LoocRsNswVq0ApHJva2slc0QfJsKkCK+1hUOk5XddOXyN RNLgyw+YV90DJeskxWdoSC/LreKODuQYDNk1XcPk= Received: from [172.16.0.192] (96-127-217-162.qc.cable.ebox.net [96.127.217.162]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 5D4031E0C0; Mon, 17 Mar 2025 11:36:59 -0400 (EDT) Message-ID: <3ae8ab32-8633-4a07-bc4f-5bdab899aa31@simark.ca> Date: Mon, 17 Mar 2025 11:36:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: Introduce user-friendly namespace identifier for "info shared" To: Guinevere Larsen , gdb-patches@sourceware.org References: <20250313170004.3362207-2-guinevere@redhat.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20250313170004.3362207-2-guinevere@redhat.com> 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 I didn't do a full review, I can review more in depth a future version (since you'll probably change the behavior of the "info shared" column anyway). I noted some high level things: On 3/13/25 1:00 PM, Guinevere Larsen wrote: > diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c > index 8378ecaff40..dabbd68d02e 100644 > --- a/gdb/solib-svr4.c > +++ b/gdb/solib-svr4.c > @@ -405,11 +405,59 @@ struct svr4_info > The special entry zero is reserved for a linear list to support > gdbstubs that do not support namespaces. */ > std::map> solib_lists; > + > + /* Mapping between r_debug[_ext] addresses and a user-friendly > + identifier for the namespace. We use both a vector and an unordered > + map for a couple of reasons. The vector is used to make it > + easy to assign new internal IDs to namespaces, and to double check > + which namespaces are still active. The map is used when we're > + rewriting the solib_lists, to make sure that IDs remain consistent > + as SOs get dlclosed and deactivate namespaces. > + > + For gdbservers that don't support namespaces, the first entry of the > + vector will be nullptr, and the map will be empty. > + > + A note on consistency. We can't make the IDs be consistent before > + and after the initial relocation of the inferior (when the global > + _r_debug is relocated, as mentioned in the previous comment). It is > + likely that this is a non-issue, since the inferior can't have called > + dlmopen yet, but I think it is worth noting. > + > + The only issue I am aware at this point is that, if when parsing an > + XML file, we read an LMID that given by an XML file (and read in > + library_list_start_library) is the identifier obtained with dlinfo > + instead of the address of r_debug[_ext], and after attaching the > + inferior adds another SO to that namespace, we might double-count it > + since we won't have access to the LMID later on. However, this is > + already a problem with the existing solib_lists code. */ > + std::vector namespace_id_vec; > + std::unordered_map namespace_id_map; Since the count of namespaces is always expected to be small, you could consider just maintaining just a vector. For example, glibc only supports a max of 16 namespaces today. Maintaining one data structure is usually easier than maintaining two in parallel. > diff --git a/gdb/solist.h b/gdb/solist.h > index 9a157a4bbae..a6822877770 100644 > --- a/gdb/solist.h > +++ b/gdb/solist.h > @@ -180,6 +180,17 @@ struct solib_ops > name). */ > > std::optional (*find_solib_addr) (solib &so); > + > + /* Return which linker namespace contains the current so. "the current so", or just "SO" (... which linker namespace contains SO)? > + If the linker or libc does not support linkage namespaces at all > + (which is basically all of them but solib-svr4), this function should > + be set to nullptr, so that "info shared" won't add an unnecessary > + column. I would not put a statement like "which is basically all of them but solib" in the interface here. It is true until it isn't. I think it's fine to sometimes mention a specific implementation in the interface documentation to explain why a certain method exists or to give an example, which helps the reader understand what the method does. But in this case I don't think mentioning solib-svr4 helps understand what find_solib_ns does. Simon