From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KJLSDkTO82dsOioAWB0awg (envelope-from ) for ; Mon, 07 Apr 2025 09:08:20 -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=hsDmbZGw; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 37F2A1E0C3; Mon, 7 Apr 2025 09:08:20 -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 035131E05C for ; Mon, 7 Apr 2025 09:08:19 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 79836384A80C for ; Mon, 7 Apr 2025 13:08:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 79836384A80C 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=hsDmbZGw Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 5AC67385696F for ; Mon, 7 Apr 2025 13:07:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5AC67385696F 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 5AC67385696F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1744031259; cv=none; b=pT4iwgFs7cAzAxU6x9r9S0pXAhuv6b0Qcbp8UKxFGK/1bdiBwCoV6CdeVuO4l6EspSg879sAHUIB8qbEQAOIATahTGErowHInl3wprifRnJmC2Ay7PMCfe6XcitPX8fRLhD7YR3s1+GlqC/X3vFD7uYW60FSZwtulq88HfwG4T8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1744031259; c=relaxed/simple; bh=wSEpB2E3YA/Bjoop4waph6InxLKm1cWshLOFh2lDixA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=T9vgEN4OvdNGi2PQIs/kF44mQ6u4wZyZXZxZBh0pm9+5M31bSDEXf3spMLMCZJBDXmTSkXrOAilo23TwXTT3B0CywjPguyZjAidc6E5Te5oa+xV00WkiR9v+PP7OvEINxECRrDxJus7ISSdbG8kGu2Mer/zkAt3foIXiJbnnmIg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5AC67385696F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744031259; 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=gv9NQnsJ7DYR5pGgXeEE/ciZWJcZc5I8iE+H4yi91SM=; b=hsDmbZGwnIibz/WB9iiTFR09qbIkGAZ67ATKzAL6ACtT3frhrwWeXdhCge33qRwgpJgvYk GXg1kQKCYn5ZY6zx7L36s+IwRWMoWV6nGvUX2LmBj4tYoQeUvdG+DyRTyY0YWIMJppbokt C9o3u5ANgPcuMq8gi6YWvsdo949a2HQ= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-29-F6jrk-LgP_Cc-pUR_WQ8YQ-1; Mon, 07 Apr 2025 09:07:37 -0400 X-MC-Unique: F6jrk-LgP_Cc-pUR_WQ8YQ-1 X-Mimecast-MFC-AGG-ID: F6jrk-LgP_Cc-pUR_WQ8YQ_1744031257 Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-7398d70abbfso6219433b3a.2 for ; Mon, 07 Apr 2025 06:07:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744031256; x=1744636056; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gv9NQnsJ7DYR5pGgXeEE/ciZWJcZc5I8iE+H4yi91SM=; b=A6EmFJzDOnHT3URJX55fyyBGWngChBgxU0n+p3WHzMPkBdw8b3UCjXCC5yxW4HKGuB xk0K30SvnwL+gjPJJypR+FVztomQ7VzNhLc09JELfhUcj+a3YZnzVTGcldHNAbEMuUaf tCtHMhqY27LzM7Ux2NZIgA41mh/luWFBnpy0eHsmRl6acN+E/BcOIiHRMdnj1M6j+vlz H/umZylT6ivfFp3GKs1/ErKdP9XuaXUVEwRSVP/2NCG3PMLAbzOGhi8TpxrgMCzsYnJ1 cZbAhOG53NpLnXNQYkJsZNt8AFDEYl2YnwRlQ9v1oLFi3wSB7VDe3+Y27bLSNqn41fus txoQ== X-Gm-Message-State: AOJu0YwS8Ja+au4zap8tS7IxzsW6IvNJoWsROHSUhSpYusggllJv50kn 1NGdSswKZf4vobIrwco+ydtob42DkwuM6DC5s0VvBYQAE4foO9DO5MbEd/kL4Z4pdIB6DoJ5zlZ Vcm6jqBKwd33aFR97c2ZdSIyktBMw+pde3BsgLrd3GvqNqBvNgGPqQgsI9inx8F3FA94= X-Gm-Gg: ASbGncuk5hSH0o7WFHYHBuD2g9mNOE3V3GcxwziwWrvp7rcG1mdoENBFY29bV/DeHwF wwulshyjEX6704kJenNR5EXx6SI4nnKU15NFSYLG54Gu9NOMrhjue7jZHZk+Mu5UP3+J7uk3fLP b0bDaL4ityFAu6SrXoLPzcCvGwr8Kzc4jjVB8iDjJwq80CNzMLTIq//tl9H6P7tEIDArECtLsvX 7u++jwP59PSAck9aVtvHLwWZuYpNloilgdrvOcEJbn0wtVU2+BXx6a3Y8msY8A1B05nLPnjur9E 0vbaypiv++JNGTm48uly1zGgOFM= X-Received: by 2002:aa7:888c:0:b0:736:4644:86ee with SMTP id d2e1a72fcca58-73b6aa72dedmr10175569b3a.14.1744031255976; Mon, 07 Apr 2025 06:07:35 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGAQvY5EzZNh7uEkymopFvxRXbHLbYQ5cAGoiXvJRjM25X8LEnBE8KrQ65XXNgubEKSVaMIIA== X-Received: by 2002:aa7:888c:0:b0:736:4644:86ee with SMTP id d2e1a72fcca58-73b6aa72dedmr10175507b3a.14.1744031255343; Mon, 07 Apr 2025 06:07:35 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:9a69::1001? ([2804:14d:8084:9a69::1001]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-739d97ee90asm8706297b3a.57.2025.04.07.06.07.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Apr 2025 06:07:34 -0700 (PDT) Message-ID: <707fd511-810a-407e-993e-1b09857c2b3b@redhat.com> Date: Mon, 7 Apr 2025 10:07:32 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] gdb: Introduce user-friendly namespace identifier for "info shared" To: Kevin Buettner Cc: gdb-patches@sourceware.org References: <20250319123035.1563282-2-guinevere@redhat.com> <20250327171312.2768622-2-guinevere@redhat.com> <20250405131731.37898256@f41-zbm-amd> From: Guinevere Larsen In-Reply-To: <20250405131731.37898256@f41-zbm-amd> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 9NBCVnXwbO8YIsuyVVdgrQ0SsveLkm5l84mqZjHgpeg_1744031257 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed 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 4/5/25 5:17 PM, Kevin Buettner wrote: > 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. >> >> 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. >> >> --- >> Changes for v3: >> * Changed the namespace identifier display from #N to [[N]] >> >> 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 Library > 0x00007ffff7fc7000 0x00007ffff7fff000 [[1]] Yes /lib64/ld-linux-x86-64.so.2 > 0x00007ffff7ea2000 0x00007ffff7f90000 [[0]] Yes (*) /lib64/libm.so.6 > 0x00007ffff7caf000 0x00007ffff7ea2000 [[0]] Yes (*) /lib64/libc.so.6 > 0x00007ffff7fbb000 0x00007ffff7fbf000 [[1]] Yes /mesquite2/sourceware-git/f42-review/bld/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-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-x86-64.so.2 > 0x00007ffff7fb7000 0x00007ffff7fbb000 [[2]] Yes /mesquite2/sourceware-git/f42-review/bld/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-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-x86-64.so.2 > 0x00007ffff7fb3000 0x00007ffff7fb7000 [[3]] Yes /mesquite2/sourceware-git/f42-review/bld/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-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-x86-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. I agree it makes sense to push this and leave final discussion of how to print the namespace, but I'll leave my thoughts here. It was a conscious decision to always display the linker namespace with the same look as how the user should input it. That's because I believe that, as much as its reasonable, we should try to make it possible for a user to figure out how to use commands without requiring that they look into the documentation. So if a user ends up dealing with an inferior with multiple namespaces, how to interact with that part of the inferior should be apparent from the moment the user realizes this is happening. In other words, we probably should print the full syntax every time. Additionally, if we print a stop location like "1::foo", a user could be confused about whether that refers to a c++ namespace named 1, or the linker namespace, so it is clear to me that we should always print "[[1]]:foo". Keeping the NS column as printing the [[]] will also help the user read that identifier and keep things consistent throughout GDB. > > 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 > Thanks for the approval. I've pushed it -- Cheers, Guinevere Larsen She/Her/Hers