gdb "cannot subscript non-array type" to index a Vec

[Hi-Angel]

Attempt to print content of a Vec at index results in error. Since it works fine for C++, I think the problem is in rustc not providing the necessary debug information for this to work.

Vecs are a widely used type, and not being able to print their content at index hurts debugging process noticeably.

Steps to reproduce (in terms of terminal commands)

$ cat -n test2.rs
     1  fn main() {
     2      let x: Vec<usize> = vec![1,2,3];
     3      println!("{:?}", x);
     4  }
$ rustc test2.rs -o a -g
$ gdb ./a
Reading symbols from ./a...
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /tmp/a.
Use `info auto-load python-scripts [REGEXP]' to list them.
gdb λ br 3
Breakpoint 1 at 0x5c05: file test2.rs, line 3.
gdb λ r
Starting program: /tmp/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Breakpoint 1, test2::main () at test2.rs:3
3           println!("{:?}", x);
gdb λ p x[0]

Expected

A print:

1

Actual

It prints:

Cannot subscript non-array type

Additional information

rustc version: rustc 1.41.0-nightly (1bd30ce2a 2019-11-15)
gdb version: 8.3.1

[Hi-Angel]

Probably related: #33014

[tromey]

See also https://sourceware.org/bugzilla/show_bug.cgi?id=21178

[Hi-Angel]

See also https://sourceware.org/bugzilla/show_bug.cgi?id=21178

Thanks! So, to be clear: is it a bug in rust compiler or in gdb? I feel like one of the reports (either this one, or the referenced one) should be closed.

[JerrieLau]

lldb is fine.

[tromey]

lldb is fine.

I'm very surprised to hear this. How does it work?

[Hi-Angel]

lldb is fine.

I'm very surprised to hear this. How does it work?

Good point. I just tested, and it turns out for me, lldb has same problem as gdb. Here's a session screenshot:

I deleted my prev. comment since it doesn't seem to be relevant now.

@JerrieLau could you please elaborate how you managed to make it work? Perhaps are you using Rust nightly and they added debug info recently? Anything else?

I tested it with lldb version 10.0.0 and rustc version 1.44.0-nightly (20fc02f83 2020-04-20)

[JerrieLau]

@Hi-Angel I just use it in my IDE(CLion). Here's a screenshot:

[Hi-Angel]

@JerrieLau what you're doing is different. You're basically treating x as a struct and unwrapping its members down to a pointer to elements. Both gdb and lldb can do that:

But as a programmer, I don't want to mess around with private internals of Rust types, which I'd need to know, and which can easily be renamed/changed from a Rust version to version.

[dario23]

the intellij-rust plugin does have some gdb-integration python code though, might be interesting to look at anyways (licensed under MIT).

[JerrieLau]

@JerrieLau what you're doing is different. You're basically treating x as a struct and unwrapping its members down to a pointer to elements. Both gdb and lldb can do that:

But as a programmer, I don't want to mess around with private internals of Rust types, which I'd need to know, and which can easily be renamed/changed from a Rust version to version.

Yes. you are right

[artemmukhin]

@JerrieLau @Hi-Angel LLDB supports accessing synthetic children via frame variable <name> command:

(lldb) frame variable vec[0]
(i32) vec[0] = 1

See https://lldb.llvm.org/use/variable.html#synthetic-children for more information:

Unlike many other visualization features, however, the access to synthetic children only works when using frame variable, and is not supported in expression

Unfortunately, just adding vec[0] watch in CLion with LLDB doesn't work yet.

@dario23 As for IJ Rust formatters, they're already upstreamed. But "cannot subscript non-array type" problem with GDB still exists.

[wesleywiser]

Visited during wg-debugging triage. I can confirm this is still an issue. Marking P-medium as making this work would be pretty useful when debugging Rust programs in gdb.