After the fix for #1031745 (thanks for the fast turnaround!), there
still is one test case (unsized.rs) that fails with gdb 13.1 (both -1
and -2), but didn't with 12.1.

I updated the reproducer repo[0], broken and good output look like this:
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, rustc_gdb_1031745::main () at src/main.rs:88
88	    zzz(); // #break
$1 = &rustc_gdb_1031745::Foo<[u8]> 0x7fffffffdd88
$2 = &rustc_gdb_1031745::Foo<rustc_gdb_1031745::Foo<[u8]>> 0x7fffffffdd88
$3 = &rustc_gdb_1031745::Foo<dyn core::fmt::Debug> {pointer: 0x555555593034, vtable: 0x5555555a3000warning: (Internal error: pc 0x5555555a3000 in read in CU, but not in symtab.)
warning: (Error: pc 0x5555555a3000 in address map, but not in symtab.)
}
$4 = alloc::boxed::Box<rustc_gdb_1031745::Foo<dyn core::fmt::Debug>, alloc::alloc::Global> {pointer: 0x5555555a7ba0, vtable: 0x5555555a3000warning: (Internal error: pc 0x5555555a3000 in read in CU, but not in symtab.)
warning: (Error: pc 0x5555555a3000 in address map, but not in symtab.)
}
$5 = &(i32, i32, [i32]) [(0, 1, 0), (2, 3, 0)]
$6 = &(i32, i32, dyn core::fmt::Debug) {pointer: 0x5555555a3020, vtable: 0x5555555a3030warning: (Internal error: pc 0x5555555a3030 in read in CU, but not in symtab.)
warning: (Error: pc 0x5555555a3030 in address map, but not in symtab.)
}
---->8----
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, rustc_gdb_1031745::main () at src/main.rs:88
88	    zzz(); // #break
$1 = &rustc_gdb_1031745::Foo<[u8]> {data_ptr: 0x7fffffffdd88, length: 4}
$2 = &rustc_gdb_1031745::Foo<rustc_gdb_1031745::Foo<[u8]>> {data_ptr: 0x7fffffffdd88, length: 4}
$3 = &rustc_gdb_1031745::Foo<dyn core::fmt::Debug> {pointer: 0x555555593034, vtable: 0x5555555a3000}
$4 = alloc::boxed::Box<rustc_gdb_1031745::Foo<dyn core::fmt::Debug>, alloc::alloc::Global> {pointer: 0x5555555a7ba0, vtable: 0x5555555a3000}
$5 = &(i32, i32, [i32]) {data_ptr: 0x555555593038, length: 2}
$6 = &(i32, i32, dyn core::fmt::Debug) {pointer: 0x5555555a3020, vtable: 0x5555555a3030}
---->8----

Since this no longer (fatally) affects the build of rustc, I opted for a
lower severity this time around. It looks like an issue with symbol
mapping/lookup again. Feel free to adjust if you consider this blocking.

0: https://salsa.debian.org/fg/rustc-gdb-1031745