rust-gdb can't call methods defined in impl blocks with generics

[apodolsk]

Consider:

use std::fmt::Debug;

#[derive(Default)]
struct Plain {
    a: usize
}

impl Plain {
    fn f(&self) {
        dbg!(self.a);
    }
}

#[derive(Default)]
struct Generic<A: Default> {
    a: A
}

impl<A: Debug + Default> Generic<A> {
    fn f(&self) {
        dbg!(&self.a);
    }

    fn f_with_its_own_generics<B: Debug>(&self, b: &B) {
        dbg!(b);
    }
}

impl Generic<usize> {
    fn f_specialized(&self) {
        dbg!(self.a);
    }
}

impl<A: Debug> Generic<Option<A>> {
    fn f_different_generics(&self) {
        dbg!(&self.a);
    }
}

fn main() {
    let p = Plain::default();
    let g1 = Generic::<usize>::default();
    let g2 = Generic::<Option<usize>>::default();

    unsafe { std::arch::asm!("int3"); }

    p.f();
    g1.f();
    g1.f_specialized();
    g1.f_with_its_own_generics(&"hello");

    g2.f();
    g2.f_different_generics();
    g2.f_with_its_own_generics(&"hello");
}

rust-gdb against a debug build of the above can evaluate p.f() and g1.f_specialized(), but not g1.f(), despite that function being present enough in the binary to break on:

Program received signal SIGTRAP, Trace/breakpoint trap.
gdb_generics_repro::main () at src/main.rs:48
48	    p.f();
(gdb) p p.f()
[src/main.rs:10:9] self.a = 0
$3 = ()
(gdb) p g1.f_specialized()
[src/main.rs:31:9] self.a = 0
$4 = ()
(gdb) p g1.f()
Could not find function named 'gdb_generics_repro::Generic<usize>::f'
(gdb) i functions .*Generic.*f
All functions matching regular expression ".*Generic.*f":

File src/main.rs:
20:	static fn gdb_generics_repro::Generic<core::option::Option<usize>>::f<core::option::Option<usize>>(*mut gdb_generics_repro::Generic<core::option::Option<usize>>);
36:	static fn gdb_generics_repro::Generic<core::option::Option<usize>>::f_different_generics<usize>(*mut gdb_generics_repro::Generic<core::option::Option<usize>>);
24:	static fn gdb_generics_repro::Generic<core::option::Option<usize>>::f_with_its_own_generics<core::option::Option<usize>, &str>(*mut gdb_generics_repro::Generic<core::option::Option<usize>>, *mut &str);
20:	static fn gdb_generics_repro::Generic<usize>::f<usize>(*mut gdb_generics_repro::Generic<usize>);
30:	static fn gdb_generics_repro::Generic<usize>::f_specialized(*mut gdb_generics_repro::Generic<usize>);
24:	static fn gdb_generics_repro::Generic<usize>::f_with_its_own_generics<usize, &str>(*mut gdb_generics_repro::Generic<usize>, *mut &str);
(gdb) b gdb_generics_repro::Generic<usize>::f<usize>
Breakpoint 4 at 0x555555569d39: file src/main.rs, line 21.

The issue is with these trailing generics after method function names, e.g. the second <usize> in gdb_generics_repro::Generic<usize>::f<usize>. They apparently correspond to the generic params of the function's containing impl, and are printed as if they're generic params of the function even for functions which aren't actually generic.

Besides being necessary for b, I see that these extra generics are necessary for lookup_symbol triggered from a python extension. But the method lookup logic in rust-lang.c seems to omit them:

value *
rust_structop::evaluate_funcall (struct type *expect_type,
				 struct expression *exp,
				 enum noside noside,
				 const std::vector<operation_up> &ops)
{
  std::vector<struct value *> args (ops.size () + 1);

  /* Evaluate the argument to STRUCTOP_STRUCT, then find its
     type in order to look up the method.  */
  args[0] = std::get<0> (m_storage)->evaluate (nullptr, exp, noside);
  /* We don't yet implement real Deref semantics.  */
  while (args[0]->type ()->code () == TYPE_CODE_PTR)
    args[0] = value_ind (args[0]);

  struct type *type = args[0]->type ();
  if ((type->code () != TYPE_CODE_STRUCT
       && type->code () != TYPE_CODE_UNION
       && type->code () != TYPE_CODE_ENUM)
      || rust_tuple_type_p (type))
    error (_("Method calls only supported on struct or enum types"));
  if (type->name () == NULL)
    error (_("Method call on nameless type"));

  std::string name = (std::string (type->name ()) + "::"
		      + std::get<1> (m_storage));

  const struct block *block = get_selected_block (0);
  struct block_symbol sym = lookup_symbol (name.c_str (), block,
					   SEARCH_FUNCTION_DOMAIN,
					   nullptr);

Generics are pretty common, so I suspect lots of people are hitting this and thinking rust-gdb just doesn't support method calls.

Is it maybe just a bug that impl generics started getting included in method names at some point? I can't see what ambiguity they'd be resolving, given that the generics of the underlying struct are also part of the symbol.

Note that the impl generics part of the name can differ from the struct generics part, as with f_different_generics() above.

cc: @tromey

Meta

rustc --version --verbose:

rustc 1.89.0-nightly (59aa1e873 2025-06-03)
binary: rustc
commit-hash: 59aa1e873028948faaf8b97e5e02d4db340ad7b1
commit-date: 2025-06-03
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5

~/code/scrap/rust/gdb_generics_repro/src: gdb --version
GNU gdb (GDB) 16.3

Backtrace

<backtrace>

[apodolsk]

gdb's rust demangler is a vendored libiberty. I thought I'd compare it to what I think is the official version at https://github.com/gcc-mirror/gcc/blob/master/libiberty/rust-demangle.c. Can confirm it's up to date:

~/prog/binutils-gdb/libiberty: diff /tmp/rust-demangle.c rust-demangle.c
~/prog/binutils-gdb/libiberty: 

Seems worth CC-ing its original authors too (@dtolnay @eddyb), though I admit I have no idea about github etiquette.

[apodolsk]

I guess libiberty is innocent, since nm appears to use it more directly, and it produces different output:

~/code/scrap/rust/gdb_generics_repro: nm -C target/debug/gdb_generics_repro | grep Generic
0000000000015d30 t gdb_generics_repro::Generic<A>::f
0000000000015db0 t gdb_generics_repro::Generic<A>::f
0000000000015e30 t gdb_generics_repro::Generic<A>::f_with_its_own_generics
0000000000015ec0 t gdb_generics_repro::Generic<A>::f_with_its_own_generics
0000000000016210 t gdb_generics_repro::Generic<usize>::f_specialized
0000000000015f50 t gdb_generics_repro::Generic<core::option::Option<A>>::f_different_generics
0000000000015fd0 t <gdb_generics_repro::Generic<A> as core::default::Default>::default
0000000000015fe0 t <gdb_generics_repro::Generic<A> as core::default::Default>::default
~/code/scrap/rust/gdb_generics_repro: nm target/debug/gdb_generics_repro | grep Generic
0000000000015d30 t _ZN18gdb_generics_repro16Generic$LT$A$GT$1f17h43b408e054a66749E
0000000000015db0 t _ZN18gdb_generics_repro16Generic$LT$A$GT$1f17h5f929bfeb69657deE
0000000000015e30 t _ZN18gdb_generics_repro16Generic$LT$A$GT$23f_with_its_own_generics17h705584c2dfdc8b0cE
0000000000015ec0 t _ZN18gdb_generics_repro16Generic$LT$A$GT$23f_with_its_own_generics17h9a1983ba633e4da1E
0000000000016210 t _ZN18gdb_generics_repro20Generic$LT$usize$GT$13f_specialized17h85cab983b88b195fE
0000000000015f50 t _ZN18gdb_generics_repro44Generic$LT$core..option..Option$LT$A$GT$$GT$20f_different_generics17h1c97d0cee73c51beE
0000000000015fd0 t _ZN79_$LT$gdb_generics_repro..Generic$LT$A$GT$$u20$as$u20$core..default..Default$GT$7default17h00caf1d5a1a33df2E
0000000000015fe0 t _ZN79_$LT$gdb_generics_repro..Generic$LT$A$GT$$u20$as$u20$core..default..Default$GT$7default17hc6e77af98f8a220bE

If I compile without debuginfo, I see that i functions .*Generic indeed starts matching nm -C output.

If I do readelf --debug-dump=info, I see the suspect extra generics baked into DW_AT_name:

 <3><92f>: Abbrev Number: 6 (DW_TAG_subprogram)
    <930>   DW_AT_linkage_name: (indirect string, offset: 0x1113ed): _ZN18gdb_generics_repro16Generic$LT$A$GT$1f17h43b408e054a66749E
    <934>   DW_AT_name        : (indirect string, offset: 0xad793): f<usize>
    <938>   DW_AT_decl_file   : 1
    <939>   DW_AT_decl_line   : 20
    <93a>   DW_AT_declaration : 1
 <4><93a>: Abbrev Number: 4 (DW_TAG_template_type_param)
    <93b>   DW_AT_type        : <0xa41>
    <93f>   DW_AT_name        : (indirect string, offset: 0x742a6): A
 <4><943>: Abbrev Number: 7 (DW_TAG_formal_parameter)
    <944>   DW_AT_type        : <0xa48>
 <4><948>: Abbrev Number: 0
 <3><949>: Abbrev Number: 6 (DW_TAG_subprogram)
    <94a>   DW_AT_linkage_name: (indirect string, offset: 0x1462e6): _ZN18gdb_generics_repro16Generic$LT$A$GT$23f_with_its_own_generics17h9a1983ba633e4da1E
    <94e>   DW_AT_name        : (indirect string, offset: 0x1253fa): f_with_its_own_generics<usize, &str>
    <952>   DW_AT_decl_file   : 1
    <953>   DW_AT_decl_line   : 24
    <954>   DW_AT_declaration : 1
 <4><954>: Abbrev Number: 4 (DW_TAG_template_type_param)
    <955>   DW_AT_type        : <0xa41>
    <959>   DW_AT_name        : (indirect string, offset: 0x742a6): A
 <4><95d>: Abbrev Number: 4 (DW_TAG_template_type_param)
    <95e>   DW_AT_type        : <0xb69>
    <962>   DW_AT_name        : (indirect string, offset: 0xdbc7c): B
 <4><966>: Abbrev Number: 7 (DW_TAG_formal_parameter)
    <967>   DW_AT_type        : <0xa48>
 <4><96b>: Abbrev Number: 7 (DW_TAG_formal_parameter)
    <96c>   DW_AT_type        : <0xb97>

[apodolsk]

There's a gdb bug report likely caused by this:
https://sourceware.org/bugzilla/show_bug.cgi?id=32471

This DW_AT_name format has been around for a long time. cargo-bisect-rustc is failing to install 2016-era rustcs for me, but I can see that the generic got added some time that year:

~/code/scrap/rust/gdb_generics_repro: cat check_dwarf.sh 
#!/bin/sh

rm -rf target && rm -rf /home/vich/code/scrap/rust/gdb_generics_repro/Cargo.lock && cargo $MANUAL build && readelf --debug-dump=info target/debug/gdb_generics_repro | grep ": f_for_grep";
COUNT=$(rm -rf target && rm -rf /home/vich/code/scrap/rust/gdb_generics_repro/Cargo.lock && cargo $MANUAL build -q 2> /dev/null && readelf --debug-dump=info target/debug/gdb_generics_repro | grep -c ": f_for_grep<")
echo $COUNT
test $COUNT -eq 0

~/code/scrap/rust/gdb_generics_repro: MANUAL=+nightly-2018-01-01 ./check_dwarf.sh  
   Compiling gdb_generics_repro v0.1.0 (file:///home/vich/code/scrap/rust/gdb_generics_repro)
    Finished dev [unoptimized + debuginfo] target(s) in 0.40 secs
    <e3e>   DW_AT_name        : (indirect string, offset: 0xa1c): f_for_grep<usize>
1
~/code/scrap/rust/gdb_generics_repro: MANUAL=+nightly-2017-01-20 ./check_dwarf.sh  
   Compiling gdb_generics_repro v0.1.0 (file:///home/vich/code/scrap/rust/gdb_generics_repro)
    Finished dev [unoptimized + debuginfo] target(s) in 0.51 secs
    <62>   DW_AT_name        : (indirect string, offset: 0xe5): f_for_grep
    <163>   DW_AT_name        : (indirect string, offset: 0x61f): f_for_grep<usize>
1
~/code/scrap/rust/gdb_generics_repro: MANUAL=+nightly-2016-01-01 ./check_dwarf.sh  
   Compiling gdb_generics_repro v0.1.0 (file:///home/vich/code/scrap/rust/gdb_generics_repro)
    <9f>   DW_AT_name        : (indirect string, offset: 0x113): f_for_grep
    <ef>   DW_AT_name        : (indirect string, offset: 0x113): f_for_grep
0

I guess if it's this old, it's probably deliberate and I'm just not seeing why impl generics matter.

Because of the f_different_generics case, it seems hard to work around such names.

If you're gdb and your goal is to compute a full method function name given a concrete struct value with known type params, you'd have to know how to relate struct generics to those of the impl block - it doesn't seem like there's info info in my dwarf dump to do it. You could instead attempt to post-process debuginfo to remove impl generics, or do some flavor of "range search" to do it at lookup time, but I can't find a way to distinguish them from real function generics either.

It's true that maybe gdb could/should ignore function generics too. I have been wondering whether rust-gdb could support generics in general by reusing some of gdb's C++ overload resolution code.

But that's a lot of effort fighting the debug info just to make vec.len() work. I'm personally here because I'm working around this in a python GDB extension and I think I have no good way to do anything except a "find the function with this exact name" search. So I currently can call methods, but only if impl generics match the struct, which isn't actually the case for the codebase which drove me to start tinkering with gdb in the first place.