pokyo. gdb -nx -quiet (gdb) set lang rust (gdb) ptype &str No symbol 'str' in current context &str is a built-in type, gdb should probably know about it. This happens when debugging a rust program as well, where &str is in the debuginfo.
This may also fall into the problem where ptype isn't trying to parse as a type. I notice that "ptype &[u8]" doesn't work either. This probably requires some core change so the parser can know if it should try a type parse (since I don't want to introduce ambiguities into the grammar)
Note that this still doesn't work even if &str appears in the DWARF. You can see this with the "simple.rs" test case in the test suite. In that case, the type appears in DWARF as "&str" but, probably, the parser here is being smart and looking up "str", which indeed does not exist. Maybe a special case is needed. See https://github.com/rust-lang/rust/issues/65272
Have a patch.
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cd61a1453e685a763bd91b3795a58edd3d9b4f40 commit cd61a1453e685a763bd91b3795a58edd3d9b4f40 Author: Tom Tromey <tom@tromey.com> Date: Wed May 17 09:07:50 2023 -0600 Special case "&str" in Rust parser "&str" is an important type in Rust -- it's the type of string literals. However, the compiler puts it in the DWARF in a funny way. The slice itself is present and named "&str". However, the Rust parser doesn't look for types with names like this, but instead tries to construct them from components. In this case it tries to make a pointer-to-"str" -- but "str" isn't always available, and in any case that wouldn't yield the best result. This patch adds a special case for &str. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22251 Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Fixed.