From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id mk+oNg2Q8Wf7MigAWB0awg (envelope-from ) for ; Sat, 05 Apr 2025 16:18:21 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=RC1qRKpw; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C6A3C1E0C3; Sat, 5 Apr 2025 16:18: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=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,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 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 EEBE81E0C0 for ; Sat, 5 Apr 2025 16:18:11 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7954A3857835 for ; Sat, 5 Apr 2025 20:18:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7954A3857835 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=RC1qRKpw Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 0048C385842D for ; Sat, 5 Apr 2025 20:17:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0048C385842D Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0048C385842D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1743884260; cv=none; b=uGEmyhunZ/8AyUXtvYASqmwYFObVRyCQdBr7cj2EXYN+/asDGpVaovWWBOPXs4AcWMh+THBXa5APAlPttpNposBl6J3IAsNkOM8ZkiWKOm0ZaMIbKcxugIKk90AIzCt6wYxRIzEHuU8G0wl+0EZ1fkn9MQ2Gh2Qw29MiR0c6Afk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1743884260; c=relaxed/simple; bh=PCEnRdvQnRatE8/GQwvpT8e9drCYPTmK+AUDetQRzvM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=SynGZMVLJMv9qreLdQ5wkTPGQYALbyZfkjOnGPZkNcu/NumqDSaBVb88vDX10QNQWvJH//8wQlaMS+2u37/EGSCQ0vMvKJbP7sGgsbSsE7vfcd/xMSWhW2Dmi3Xzo7r1cE2Uz1m+hLj0b3/JRQ6uzrrWTDayilAgYGu1Ebi34bE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0048C385842D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743884259; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+afl0rilAnoyiNIpsBPIZuDUEHUsnK4DNPz9o2zXIAU=; b=RC1qRKpwoI+gh0iRKsrARQTW8v+L8PrjH9fJzafjDyYE26LaO08sKoC+LNQfe/RDcONpfp 80fdrlI7Ax3NwJxGyUdbCpjqJpCdCP1RQrc7BEcMNShlyOHxTTx3jzsR/i4eUU/OmiMKZz 7kEY+lwIoVQGdbPoH8z7WsuImbJC+Xc= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-54-NZPPe28wPCimE2ZC3xtZug-1; Sat, 05 Apr 2025 16:17:38 -0400 X-MC-Unique: NZPPe28wPCimE2ZC3xtZug-1 X-Mimecast-MFC-AGG-ID: NZPPe28wPCimE2ZC3xtZug_1743884257 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5995B1800349 for ; Sat, 5 Apr 2025 20:17:37 +0000 (UTC) Received: from f41-zbm-amd (unknown [10.22.88.7]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6E2CF192C7C3; Sat, 5 Apr 2025 20:17:35 +0000 (UTC) Date: Sat, 5 Apr 2025 13:17:31 -0700 From: Kevin Buettner To: Guinevere Larsen Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v3] gdb: Introduce user-friendly namespace identifier for "info shared" Message-ID: <20250405131731.37898256@f41-zbm-amd> In-Reply-To: <20250327171312.2768622-2-guinevere@redhat.com> References: <20250319123035.1563282-2-guinevere@redhat.com> <20250327171312.2768622-2-guinevere@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: UXGi0B3Az14p0aMAgTcts3WhCjD94F2kkvUUcO5Qh4g_1743884257 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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 Thu, 27 Mar 2025 14:13:13 -0300 Guinevere Larsen wrote: > This commit is the first step in improving the user experience around > multiple namespace support. It introduces a user-friendly identifier for > namespaces, in the format [[]], that will keep consistent between > dlmopen and dlclose calls. The plan is for this identifier to be usable > in expressions like `print [[1]]::var` to find a specific instance of a > symbol, and so the identifier must not be a valid C++ or Ada namespace > identifier, otherwise disambiguation becomes a problem. Support for > those expressions has not been implemented yet, it is only mentioned to > explain why the identifier looks like this. This syntax seems okay to me. (I don't have a better suggestion.) > This syntax was chosen based on the C attributes, since nothing in GDB > uses a similar syntax that could confuse users. Other syntax options > that were explored were "#" and "@". The former was > abandoned because when printing a frame, the frame number is also > printed with #, so in a lot of the context in which that the > identifier would show up, it appears in a confusing way. The latter > clashes with the array printing syntax, and I believe that the having > "@N::foo" working completely differently to "foo@2" would also lead to a > bad user experience. Thanks for explaining the other options considered. > The namespace identifiers are stored via a vector inside svr4_info > object. The vector stores the address of the r_debug objects used by > glibc to identify each namespace, and the user-friendly ID is the index > of the r_debug in the vector. This commit also introduces a set storing > the indices of active namespaces. The glibc I used to develop this patch > (glibc 2.40 on Fedora 41) doesn't allow an SO to be loaded into a > deactivated namespace, and requesting a new namespace when a namespace > was previously closed will reuse that namespace. Because of how this is > implemented, this patch lets GDB easily track the exact namespace IDs > that the inferior will see. >=20 > Finally, two new solib_ops function pointers were added, find_solib_ns > and num_active_namespaces, to allow code outside of solib-svr4 to find > and use the namespace identifiers and the number of namespaces, > respectively. As a sanity check, the command `info sharedlibrary` has > been changed to display the namespace identifier when the inferior has > more than one active namespace. With this final change, a couple of tests > had to be tweaked to handle the possible new column, and a new test has > been created to make sure that the column appears and disappears as > needed, and that GDB can track the value of the LMID for namespaces. >=20 > --- > Changes for v3: > * Changed the namespace identifier display from #N to [[N]] >=20 > Changes for v2: > * made it so the new column in "info shared" only shows up when multiple > namespaces are active > * changes NEWS and docs to reflect that > * Added a test for this functionality Your solib related changes and the new tests look good to me. The only (slight) misgiving I have is related to identifier being printed in the NS column... (gdb) info sharedlibrary >From To NS Syms Read Shared Object Lib= rary 0x00007ffff7fc7000 0x00007ffff7fff000 [[1]] Yes /lib64/ld-linux-x= 86-64.so.2 0x00007ffff7ea2000 0x00007ffff7f90000 [[0]] Yes (*) /lib64/libm.so.6 0x00007ffff7caf000 0x00007ffff7ea2000 [[0]] Yes (*) /lib64/libc.so.6 0x00007ffff7fbb000 0x00007ffff7fbf000 [[1]] Yes /mesquite2/source= ware-git/f42-review/bld/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmop= en-lib.so 0x00007ffff7b8f000 0x00007ffff7c7d000 [[1]] Yes (*) /lib64/libm.so.6 0x00007ffff799c000 0x00007ffff7b8f000 [[1]] Yes (*) /lib64/libc.so.6 0x00007ffff7fc7000 0x00007ffff7fff000 [[1]] Yes /lib64/ld-linux-x= 86-64.so.2 0x00007ffff7fb7000 0x00007ffff7fbb000 [[2]] Yes /mesquite2/source= ware-git/f42-review/bld/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmop= en-lib.so 0x00007ffff78ae000 0x00007ffff799c000 [[2]] Yes (*) /lib64/libm.so.6 0x00007ffff76bb000 0x00007ffff78ae000 [[2]] Yes (*) /lib64/libc.so.6 0x00007ffff7fc7000 0x00007ffff7fff000 [[1]] Yes /lib64/ld-linux-x= 86-64.so.2 0x00007ffff7fb3000 0x00007ffff7fb7000 [[3]] Yes /mesquite2/source= ware-git/f42-review/bld/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmop= en-lib.so 0x00007ffff75cd000 0x00007ffff76bb000 [[3]] Yes (*) /lib64/libm.so.6 0x00007ffff73da000 0x00007ffff75cd000 [[3]] Yes (*) /lib64/libc.so.6 0x00007ffff7fc7000 0x00007ffff7fff000 [[1]] Yes /lib64/ld-linux-x= 86-64.so.2 I'm wondering if it might be better to print just (e.g.) "1" instead of "[[1]]". The argument in favor of the way you're doing it is that it may be a reminder of the syntax that'll (eventually) be used to specify linker namespaces in expressions. Since it is kind of odd and may be difficult to remember, especially since this is such a niche feature, I think it's okay. I think this patch should go in so that further progress can be made on linker namespace support. Quibbles regarding whether the NS column should have the square brackets or not can be addressed in later patches if necessary. The approval give below assumes that you've fixed the testcase as mentioned in reply. (I ran into this and added your fix to my local sources for testing. FWIW, I tested on x86_64, aarch64, and riscv.) Approved-by: Kevin Buettner