Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Guinevere Larsen <guinevere@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH v2] gdb: Introduce user-friendly namespace identifier for "info shared"
Date: Fri, 21 Mar 2025 14:55:04 -0300	[thread overview]
Message-ID: <84bfb517-945b-4ac0-94f7-9469c9b04501@redhat.com> (raw)
In-Reply-To: <20250319123035.1563282-2-guinevere@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 9646 bytes --]

On 3/19/25 9:30 AM, Guinevere Larsen wrote:
> GDB has had basic support for linkage namespaces for some time already,
> but only in the sense of managing multiple copies of the same shared
> object being loaded, and a very fragile way to find the correct copy of
> a symbol (see PR shlibs/32054).
>
> 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 #<number>, 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.

While doing some more development on the next patch for this series, it 
occurred to me that we also identify frames with #N, so this would be 
overlap of the meaning of #. This will eventually be somewhat confusing 
as we could possibly have the following:

(gdb) bt
#0  #1::roll () at random.c:6
#1  0x00000000004011b8 in #1::hit (chance=0, acc_boost=0, 
evasion_boost=0) at random.c:9
#2  0x000000000040126c in #0::main () at random.c:20

My question is: is this confusing enough that we should figure out a 
different syntax? and if so, what other invalid character should I use 
for a namespace?

Also I have an unrelated note about my patch inlined.

>
> 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.
>
> ---
<snipping for convenience>
> diff --git a/gdb/testsuite/gdb.base/dlmopen-ns-ids.exp b/gdb/testsuite/gdb.base/dlmopen-ns-ids.exp
> new file mode 100644
> index 00000000000..890ee091be9
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/dlmopen-ns-ids.exp
> @@ -0,0 +1,108 @@
> +# This testcase is part of GDB, the GNU debugger.
> +#
> +# Copyright 2025 Free Software Foundation, Inc.
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see<http://www.gnu.org/licenses/>.
> +#
> +#
> +# Test several things related to handling linker namespaces:
> +# * That the user-facing namespace ID is consistent;
> +
> +require allow_dlmopen_tests
> +
> +standard_testfile -main.c -lib.c
> +
> +set srcfile_lib $srcfile2
> +set binfile_lib [standard_output_file dlmopen-lib.so]
> +
> +if { [build_executable "build shlib" $binfile_lib $srcfile_lib \
> +	  [list debug shlib]] == -1 } {
> +    return
> +}
> +
> +if { [build_executable "failed to build" $testfile $srcfile \
> +	  [list additional_flags=-DDSO_NAME=\"$binfile_lib\" \
> +	       shlib_load debug]] } {
> +    return
> +}
> +
> +# Run the command "info sharedlibrary" and get the first namespace
> +# for the so
> +proc get_first_so_ns {} {
> +    set ns -1
> +    gdb_test_multiple "info sharedlibrary" "get SO namespace" -lbl {
> +	-re "From\\s+To\\s+\(NS\\s+\)?Syms\\s+Read\\s+Shared Object Library\r\n" {
> +	    exp_continue
> +	}
> +	-re "^$::hex\\s+$::hex\\s+\#($::decimal)\\s+\[^\r\n]+$::binfile_lib.*" {
> +	    set ns $expect_out(1,string)
> +	}
> +	-re "^$::gdb_prompt $" {
> +	}
> +	-re "^\[^\r\n\]+\r\n" {
> +	    exp_continue
> +	}
> +    }
> +    return $ns
> +}
> +
> +# Run the tests relating to the command "info sharedlibrary", to
> +# verify that the namespace ID is consistent.
> +proc test_info_shared {} {
> +    clean_restart $::binfile
> +
> +    if { ![runto_main] } {
> +	return
> +    }
> +
> +    # First test that we don't print a namespace column at the start.
> +    gdb_test "info sharedlibrary" \
> +	"From\\s+To\\s+Syms\\s+Read\\s+Shared Object Library.*" \
> +	"before loading anything"
> +
> +    gdb_test_no_output "set wait_for_gdb = 0"

This is leftover from an earlier version where I thought about using 
attach, but decided against it since dlmopen already tests it.

I've removed this from my local branch

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

> +
> +    gdb_breakpoint [gdb_get_line_number "TAG: first dlclose"]
> +    gdb_continue_to_breakpoint "TAG: first dlclose"
> +
> +    # Next, test that we *do* print a namespace column after loading SOs.
> +    gdb_test "info sharedlibrary" \
> +	"From\\s+To\\s+NS\\s+Syms\\s+Read\\s+Shared Object Library.*" \
> +	"after loading everything"
> +
> +    gdb_assert {[get_first_so_ns] == 1} "before closing any library"
> +
> +    gdb_test "next" ".*second dlclose.*" "close first library"
> +    gdb_assert {[get_first_so_ns] == 2} "after closing one library"
> +
> +    gdb_test "next" ".*third dlclose.*" "close second library"
> +    gdb_assert {[get_first_so_ns] == 3} "before closing two libraries"
> +
> +    gdb_breakpoint [gdb_get_line_number "TAG: fourth dlclose"]
> +    gdb_continue_to_breakpoint "TAG: fourth dlclose"
> +    # As of writing this test, glibc's LMID is just an index on an array of
> +    # namespaces.  After closing a namespace, requesting a new one will
> +    # return the index of the lowest-closed namespace, so this will likely
> +    # be namespace 1, and because of glibc's reuse of the r_debug object,
> +    # GDB should be able to assign the same number.
> +    gdb_assert {[get_first_so_ns] == [get_integer_valueof "lmid" "-1"]} \
> +	"reopen a namespace"
> +
> +    gdb_test "next" ".*return 0.*" "final namespace inactive"
> +    gdb_test "info sharedlibrary" \
> +	"From\\s+To\\s+Syms\\s+Read\\s+Shared Object Library.*" \
> +	"after unloading everything"
> +}
> +
> +test_info_shared
> diff --git a/gdb/testsuite/gdb.base/dlmopen.exp b/gdb/testsuite/gdb.base/dlmopen.exp
> index a8e3b08c016..6f8a3bc9de4 100644
> --- a/gdb/testsuite/gdb.base/dlmopen.exp
> +++ b/gdb/testsuite/gdb.base/dlmopen.exp
> @@ -106,7 +106,7 @@ proc check_dso_count { dso num } {
>   
>       set count 0
>       gdb_test_multiple "info shared" "info shared" {
> -	-re "$hex  $hex  Yes \[^\r\n\]*$dso\r\n" {
> +	-re "$hex  $hex  \(\#$::decimal\\s+\)\?Yes \[^\r\n\]*$dso\r\n" {
>   	    # use longer form so debug remote does not interfere
>   	    set count [expr $count + 1]
>   	    exp_continue
> @@ -233,12 +233,12 @@ proc get_dyld_info {} {
>       set dyld_count 0
>       set dyld_start_addr ""
>       gdb_test_multiple "info sharedlibrary" "" {
> -	-re "From\\s+To\\s+Syms\\s+Read\\s+Shared Object Library\r\n" {
> +	-re "From\\s+To\\s+\(NS\\s+\)?Syms\\s+Read\\s+Shared Object Library\r\n" {
>   	    exp_continue
>   	}
> -	-re "^($::hex)\\s+$::hex\\s+\[^/\]+(/\[^\r\n\]+)\r\n" {
> +	-re "^($::hex)\\s+$::hex\\s+\(\#$::decimal\\s+\)?\[^/\]+(/\[^\r\n\]+)\r\n" {
>   	    set addr $expect_out(1,string)
> -	    set lib $expect_out(2,string)
> +	    set lib $expect_out(3,string)
>   
>   	    if { [is_dyln $lib] } {
>   		# This looks like it might be the dynamic linker.
> diff --git a/gdb/testsuite/gdb.mi/mi-dlmopen.exp b/gdb/testsuite/gdb.mi/mi-dlmopen.exp
> index a5743f83bb8..c0208ebcc51 100644
> --- a/gdb/testsuite/gdb.mi/mi-dlmopen.exp
> +++ b/gdb/testsuite/gdb.mi/mi-dlmopen.exp
> @@ -81,12 +81,12 @@ proc get_dyld_info {} {
>       set dyld_count 0
>       set dyld_start_addr ""
>       gdb_test_multiple "info sharedlibrary" "" {
> -	-re "~\"From\\s+To\\s+Syms\\s+Read\\s+Shared Object Library\\\\n\"\r\n" {
> +	-re "~\"From\\s+To(\\s+NS)?\\s+Syms\\s+Read\\s+Shared Object Library\\\\n\"\r\n" {
>   	    exp_continue
>   	}
> -	-re "^~\"($::hex)\\s+$::hex\\s+\[^/\]+(/\[^\r\n\]+)\\\\n\"\r\n" {
> +	-re "^~\"($::hex)\\s+${::hex}(\\s+$::decimal)?\\s+\[^/\]+(/\[^\r\n\]+)\\\\n\"\r\n" {
>   	    set addr $expect_out(1,string)
> -	    set lib $expect_out(2,string)
> +	    set lib $expect_out(3,string)
>   
>   	    if { [is_dyln $lib] } {
>   		# This looks like it might be the dynamic linker.
>
> base-commit: 82455bdab80f9a4d4f94a6e8590a1bdc58c4010e

[-- Attachment #2: Type: text/html, Size: 10393 bytes --]

  reply	other threads:[~2025-03-21 17:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 17:00 [PATCH] " Guinevere Larsen
2025-03-13 19:19 ` Eli Zaretskii
2025-03-13 19:27   ` Guinevere Larsen
2025-03-15  2:51 ` Kevin Buettner
2025-03-15  3:11   ` Kevin Buettner
2025-03-17 11:55     ` Guinevere Larsen
2025-03-17 15:36       ` Simon Marchi
2025-03-18  1:07       ` Kevin Buettner
2025-03-17 15:36 ` Simon Marchi
2025-03-17 17:07   ` Guinevere Larsen
2025-03-17 17:54     ` Simon Marchi
2025-03-19 12:30 ` [PATCH v2] " Guinevere Larsen
2025-03-21 17:55   ` Guinevere Larsen [this message]
2025-03-27 17:13   ` [PATCH v3] " Guinevere Larsen
2025-03-31 19:34     ` Guinevere Larsen
2025-04-05 20:17     ` Kevin Buettner
2025-04-07 13:07       ` Guinevere Larsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84bfb517-945b-4ac0-94f7-9469c9b04501@redhat.com \
    --to=guinevere@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox