gdb 8.1 fails debuginfo tests (output changed).

[eddyb]

AFAICT, it appears to print module::Enum::Variant {...} instead of module::Variant {...} now.

cc @tromey @michaelwoerister

[eddyb]

@Pazzaz Hmm, do you specifically want more information? The build server I use is NixOS and it was updated recently, which appears to have picked up gdb 8.1, which has slightly different output.

[nnethercote]

I have the same or a similar problem:

failures:
    [debuginfo-gdb] debuginfo/borrowed-c-style-enum.rs
    [debuginfo-gdb] debuginfo/borrowed-enum.rs
    [debuginfo-gdb] debuginfo/c-style-enum-in-composite.rs
    [debuginfo-gdb] debuginfo/gdb-pretty-struct-and-enums-pre-gdb-7-7.rs
    [debuginfo-gdb] debuginfo/generic-enum-with-different-disr-sizes.rs
    [debuginfo-gdb] debuginfo/generic-struct-style-enum.rs
    [debuginfo-gdb] debuginfo/generic-tuple-style-enum.rs
    [debuginfo-gdb] debuginfo/struct-style-enum.rs
    [debuginfo-gdb] debuginfo/tuple-style-enum.rs
    [debuginfo-gdb] debuginfo/unique-enum.rs

I'm on Ubuntu 18.04, using gdb 8.1.

[Pazzaz]

@eddyb It was that I encountered the bug on my own machine, running Ubuntu 18.04 and gdb 8.1. (same as nnethercote)

[joshtriplett]

Encountered this on current Debian unstable with gdb 8.1.

[tromey]

I think the new output is more correct and so the thing to do is update the tests.

I looked through the gdb 8.1 git log, searching for a change that would affect this. All I found, though, was this commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ec8df23454873916c6b6b918967af631b268acd8

... which claims that the change was in rustc, not gdb.

[eddyb]

cc @alexcrichton Can we reasonably update the tests?

[alexcrichton]

So long as we're still running tests on CI seems fine by me (I forget if we have min-gdb-version yet)

[michaelwoerister]

I would be awesome to mostly base our tests on gimli or llvm-dwarfdump...

[tromey]

So long as we're still running tests on CI seems fine by me (I forget if we have min-gdb-version yet)

Yes, we do. Somewhere also there was a PR that built a local gdb in travis. Though now that 8.2 is officially out perhaps it isn't too hard to upgrade some config somewhere.

[tromey]

It was #53497, but I'm also talking with Matthias Klose about getting a newer gdb into the Ubuntu toolchain PPA, which would be a lot simpler I think.

[alexcrichton]

@tromey ok great! All of our builds are pretty self-contained and independently upgradeable, so it should be fine to move a builder to Ubuntu 18.04 from where it's at now (that's what I'm running locally now and see these failures). We could then tag everything with a minimum version and they'll only get run on this one bot

[tromey]

FWIW testing locally I can only get failures with gdb 8.2 and later, not 7.11 or 8.1. Perhaps Ubuntu's "8.1" is actually based on something later. This may complicate the version check.

[tromey]

I think the new output is more correct and so the thing to do is update the tests.

Well, that seems wrong to me now.

The test says:

// gdbr-check:$1 = borrowed_c_style_enum::ABC::TheA

And when I update the Dockerfile and run the tests I get:

$1 = borrowed_c_style_enum::TheA

I think what is happening here is that LLVM is not emitting DW_AT_enum_class on these enums. I'm not sure how to dig this out of the docker build but I saw this while working on #54004, which is why that patch has the IsFixed enum stuff.

This applies to the C-style enum fails, but the others seem similar. More later after I rebuild & see if I can provoke it in a more debuggable way.

[tromey]

I can't reproduce with a clean build of git master and gdb 8.1, but I can via an update Dockerfile. I wonder if there's some LLVM difference between these two builds somehow.

[tromey]

I do see some differences with gdb 8.2. For example:

$1 = generic_enum_with_different_disr_sizes::Enum<f64>::Variant1(100)

Here the <f64> is new. I believe this is due to a gdb change in advance of #54004, changing how Rust enums are represented internally in gdb.

Since Matthias put gdb into the Ubuntu toolchain PPA perhaps instead we can just update to 8.2 and go from there. I'll give it a try.

[tromey]

I'm going to put this into the #54004 series to avoid making extra rebasing work for myself. But first I think we're going to need a way to specify the maximum LLVM version in the tests so we can continue to properly test fallback cases.

[tromey]

I couldn't reproduce this today with git master; I tried running the debuginfo tests against gdb 7.11, gdb 8.1, and gdb 8.2.

[nnethercote]

It's no longer reproducing for me, either.

[tromey]

I'm closing it, if someone else reproduces please re-open or re-file. Thanks.

[vext01]

Hi,

I don't have privs to re-open the bug, but I get gdb compiletest failures reproducibly on today's master (046e054a995) using gdb 7.11.1, 7.12 and 8.1. I'm using Debian 9.

For example, using gdb-8.1 (fresh clone and build):

$ PATH=/opt/gdb/bin:${PATH} ./x.py test --stage 2
...
running 118 tests
.iiiii..i......i..i...i..i.i..i.iFi.....i..i.....i..........iiii.........i.i..FFiF.i........ii.i.ii. 100/118
.....i.iii......ii
failures:

---- [debuginfo-both] debuginfo/gdb-pretty-struct-and-enums-pre-gdb-7-7.rs stdout ----
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 8002000

error: line not found in debugger output: $1 = RegularStruct = {the_first_field = 101, the_second_field = 102.5, the_third_field = false}
status: exit code: 0
command: "/opt/gdb/bin/gdb" "-quiet" "-batch" "-nx" "-command=/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/gdb-pretty-struct-and-enums-pre-gdb-7-7/gdb-pretty-struct-and-enums-pre-gdb-7-7.debugger.script"
stdout:
------------------------------------------
GNU gdb (GDB) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0xacf: file /home/vext01/source/rust/src/test/debuginfo/gdb-pretty-struct-and-enums-pre-gdb-7-7.rs, line 70.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, gdb_pretty_struct_and_enums_pre_gdb_7_7::main () at /home/vext01/source/rust/src/test/debuginfo/gdb-pretty-struct-and-enums-pre-gdb-7-7.rs:70
70	    zzz(); // #break
$1 = gdb_pretty_struct_and_enums_pre_gdb_7_7::RegularStruct {the_first_field: 101, the_second_field: 102.5, the_third_field: false}
$2 = gdb_pretty_struct_and_enums_pre_gdb_7_7::EmptyStruct
$3 = gdb_pretty_struct_and_enums_pre_gdb_7_7::CStyleEnum::CStyleEnumVar1
$4 = gdb_pretty_struct_and_enums_pre_gdb_7_7::CStyleEnum::CStyleEnumVar2
$5 = gdb_pretty_struct_and_enums_pre_gdb_7_7::CStyleEnum::CStyleEnumVar3
A debugging session is active.

	Inferior 1 [process 18799] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

------------------------------------------
stderr:
------------------------------------------
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/vext01/source/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/gdb-pretty-struct-and-enums-pre-gdb-7-7/a.
Use `info auto-load python-scripts [REGEXP]' to list them.

------------------------------------------

thread '[debuginfo-both] debuginfo/gdb-pretty-struct-and-enums-pre-gdb-7-7.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3282:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- [debuginfo-both] debuginfo/pretty-huge-vec.rs stdout ----
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 8002000

error: line not found in debugger output: $1 = Vec<u8>(len: 1000000000, cap: 1000000000) = {[...]...}
status: exit code: 0
command: "/opt/gdb/bin/gdb" "-quiet" "-batch" "-nx" "-command=/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-huge-vec/pretty-huge-vec.debugger.script"
stdout:
------------------------------------------
GNU gdb (GDB) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0x14ea: file /home/vext01/source/rust/src/test/debuginfo/pretty-huge-vec.rs, line 38.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, pretty_huge_vec::main () at /home/vext01/source/rust/src/test/debuginfo/pretty-huge-vec.rs:38
38	    zzz(); // #break
$1 = alloc::vec::Vec<u8> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {ptr: core::ptr::Unique<u8> {pointer: core::nonzero::NonZero<*const u8> (0x7fffbb54b010 "\000"), _marker: core::marker::PhantomData<u8>}, cap: 1000000000, a: alloc::alloc::Global}, len: 1000000000}
$2 = &[u8] {data_ptr: 0x7fffbb54b010 "\000", length: 1000000000}
A debugging session is active.

	Inferior 1 [process 19518] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

------------------------------------------
stderr:
------------------------------------------
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/vext01/source/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-huge-vec/a.
Use `info auto-load python-scripts [REGEXP]' to list them.

------------------------------------------

thread '[debuginfo-both] debuginfo/pretty-huge-vec.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3282:9

---- [debuginfo-both] debuginfo/pretty-std-collections.rs stdout ----
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 8002000

error: line not found in debugger output: $1 = BTreeSet<i32>(len: 3) = {3, 5, 7}
status: exit code: 0
command: "/opt/gdb/bin/gdb" "-quiet" "-batch" "-nx" "-command=/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-std-collections/pretty-std-collections.debugger.script"
stdout:
------------------------------------------
GNU gdb (GDB) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0x11066: file /home/vext01/source/rust/src/test/debuginfo/pretty-std-collections.rs, line 57.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, pretty_std_collections::main () at /home/vext01/source/rust/src/test/debuginfo/pretty-std-collections.rs:57
57	    zzz(); // #break
$1 = alloc::collections::btree::set::BTreeSet<i32> {map: alloc::collections::btree::map::BTreeMap<i32, ()> {root: alloc::collections::btree::node::Root<i32, ()> {node: alloc::collections::btree::node::BoxedNode<i32, ()> {ptr: core::ptr::Unique<alloc::collections::btree::node::LeafNode<i32, ()>> {pointer: core::nonzero::NonZero<*const alloc::collections::btree::node::LeafNode<i32, ()>> (0x555555774130), _marker: core::marker::PhantomData<alloc::collections::btree::node::LeafNode<i32, ()>>}}, height: 0}, length: 3}}
$2 = alloc::collections::btree::map::BTreeMap<i32, i32> {root: alloc::collections::btree::node::Root<i32, i32> {node: alloc::collections::btree::node::BoxedNode<i32, i32> {ptr: core::ptr::Unique<alloc::collections::btree::node::LeafNode<i32, i32>> {pointer: core::nonzero::NonZero<*const alloc::collections::btree::node::LeafNode<i32, i32>> (0x555555774170), _marker: core::marker::PhantomData<alloc::collections::btree::node::LeafNode<i32, i32>>}}, height: 0}, length: 3}
$3 = alloc::collections::vec_deque::VecDeque<i32> {tail: 0, head: 3, buf: alloc::raw_vec::RawVec<i32, alloc::alloc::Global> {ptr: core::ptr::Unique<i32> {pointer: core::nonzero::NonZero<*const i32> (0x5555557741e0), _marker: core::marker::PhantomData<i32>}, cap: 8, a: alloc::alloc::Global}}
A debugging session is active.

	Inferior 1 [process 19548] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

------------------------------------------
stderr:
------------------------------------------
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/vext01/source/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-std-collections/a.
Use `info auto-load python-scripts [REGEXP]' to list them.

------------------------------------------

thread '[debuginfo-both] debuginfo/pretty-std-collections.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3282:9

---- [debuginfo-both] debuginfo/pretty-uninitialized-vec.rs stdout ----
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 8002000

error: line not found in debugger output: $1 = Vec<i32>(len: [...], cap: [...])[...]
status: exit code: 0
command: "/opt/gdb/bin/gdb" "-quiet" "-batch" "-nx" "-command=/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-uninitialized-vec/pretty-uninitialized-vec.debugger.script"
stdout:
------------------------------------------
GNU gdb (GDB) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0x1004: file /home/vext01/source/rust/src/test/debuginfo/pretty-uninitialized-vec.rs, line 31.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, pretty_uninitialized_vec::main () at /home/vext01/source/rust/src/test/debuginfo/pretty-uninitialized-vec.rs:31
31	    zzz(); // #break
$1 = alloc::vec::Vec<i32> {buf: alloc::raw_vec::RawVec<i32, alloc::alloc::Global> {ptr: core::ptr::Unique<i32> {pointer: core::nonzero::NonZero<*const i32> (0x5555557580a0), _marker: core::marker::PhantomData<i32>}, cap: 93824992237456, a: alloc::alloc::Global}, len: 93824992233728}
A debugging session is active.

	Inferior 1 [process 19578] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

------------------------------------------
stderr:
------------------------------------------
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/vext01/source/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-uninitialized-vec/a.
Use `info auto-load python-scripts [REGEXP]' to list them.

------------------------------------------

thread '[debuginfo-both] debuginfo/pretty-uninitialized-vec.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3282:9


failures:
    [debuginfo-both] debuginfo/gdb-pretty-struct-and-enums-pre-gdb-7-7.rs
    [debuginfo-both] debuginfo/pretty-huge-vec.rs
    [debuginfo-both] debuginfo/pretty-std-collections.rs
    [debuginfo-both] debuginfo/pretty-uninitialized-vec.rs

test result: FAILED. 78 passed; 4 failed; 36 ignored; 0 measured; 0 filtered out

thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:503:22


command did not execute successfully: "/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/home/vext01/source/rust/src/test/debuginfo" "--build-base" "/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/test/debuginfo" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "debuginfo-both" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/home/vext01/source/rust/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python" "--lldb-python" "/usr/bin/python" "--gdb" "/opt/gdb/bin/gdb" "--quiet" "--llvm-version" "8.0.0svn\n" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" ""
expected success, got: exit code: 101


failed to run: /home/vext01/source/rust/build/bootstrap/debug/bootstrap test --stage 2
Build completed unsuccessfully in 0:00:14

Is this line anything to do with it?

warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts

Thanks

[vext01]

Also tried with gdb-8.1. No joy.

[tromey]

Some of these tests are being changed by patches already in the queue. However for pretty-std-collections:

error: line not found in debugger output: $1 = BTreeSet<i32>(len: 3) = {3, 5, 7}
[...]
$1 = alloc::collections::btree::set::BTreeSet<i32> {map: alloc::collections::btree::map::BTreeMap<i32, ()> {root: alloc::collections::btree::node::Root<i32, ()> {node: alloc::collections::btree::node::BoxedNode<i32, ()> {ptr: core::ptr::Unique<alloc::collections::btree::node::LeafNode<i32, ()>> {pointer: core::nonzero::NonZero<*const alloc::collections::btree::node::LeafNode<i32, ()>> (0x555555774130), _marker: core::marker::PhantomData<alloc::collections::btree::node::LeafNode<i32, ()>>}}, height: 0}, length: 3}}

This test is trying to test the gdb pretty-printers, but the actual output seems to indicate that they aren't firing.

[vext01]

Does it use an "auto-load script" by any chance? There's that rather fishy line in the output:

warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts

This is a pretty minimal install I'm testing on.Perhaps I'm missing a test dependency?

Anything you'd like me to try?

[vext01]

I don't need debuginfo enabled in config.toml, do I?

[tromey]

Does it use an "auto-load script" by any chance?

Yes. Did you build your gdb with Python enabled? If that were missing I think it would cause this error.

[vext01]

That's probably the issue.

[tromey]

If you can try rebuilding gdb against Python, that would tell us for sure. Otherwise, if you'd rather not, then I think we should re-close this bug. Please let me know, thanks.

[vext01]

Just trying it now. Bear with me.

[vext01]

gdb has python support alright:

$ ldd /opt/gdb-8.2/bin/gdb
        linux-vdso.so.1 (0x00007ffe701eb000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc901463000)
        libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007fc900ed1000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc900cb4000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fc900ab1000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc9007ad000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fc900583000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc9001e4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc9020e6000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc8fffca000)

failures:
    [debuginfo-both] debuginfo/gdb-pretty-struct-and-enums-pre-gdb-7-7.rs
    [debuginfo-both] debuginfo/pretty-huge-vec.rs
    [debuginfo-both] debuginfo/pretty-std-collections.rs
    [debuginfo-both] debuginfo/pretty-uninitialized-vec.rs

Same auto-load warning present. Also tried python-3.5.

Any other ideas?

[tromey]

As far as I know, something going wrong with Python scripting is the only reason to get that auto-load error. One idea would be to double-check what is going on by adding lines like this to one of the test .rs files:

// gdb-command: show config
// gdb-command: info auto-load python-scripts

... then post the output from that test. You can also check that python works like:

// gdb-command: python print("it works")

[vext01]

// gdb-command: python print("it works")

That does work. I already tried it.

Watch this space for the other output.

[vext01]

Sorry, I had the PATH set to the old non-python enabled gdb!

It didn't crash those tests using the right gdb.

It might be worth mentioning somewhere (compiler guide?) that you need a python enabled gdb? Also, which version of python is preferred?

[tromey]

It might be worth mentioning somewhere (compiler guide?) that you need a python enabled gdb?

Yeah.

Also, which version of python is preferred?

It shouldn't matter as far as either gdb or the rust pretty-printers are concerned.

[tromey]

I'm going to re-close this now.

[vext01]

Please go ahead. And thanks for the help.

Do you want me to raise a PR on the compiler guide?

[tromey]

Do you want me to raise a PR on the compiler guide?

Sure, thanks.

[eddyb]

Why don't we detect python support in compiletest to avoid such issues?