Re: gdb issues?

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

following up on my own message, I finally had the presence of
mind to look at what gdb on armv7 would tell me, if anything,
because that build failed as well.

And... it tells quite a bit more than the other two:

armv7: {2} gdb /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/build/bootstrap/debug/bootstrap work/rustc-1.73.0-src/bootstrap.core
GNU gdb (GDB) 8.3
Copyright (C) 2019 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 "armv7--netbsdelf-eabihf".
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"...
Reading symbols from /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/build/bootstrap/debug/bootstrap...
[New process 1]
Core was generated by `bootstrap'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x60d0fe74 in _cpuset_isset () from /usr/lib/libc.so.12
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/build/bootstrap/debug/bootstrap.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) where
#0  0x60d0fe74 in _cpuset_isset () from /usr/lib/libc.so.12
#1  0x03d2bf8c in std::sys::unix::thread::available_parallelism ()
#2  0x03cff460 in std::thread::available_parallelism ()
#3  0x0383ed74 in <bootstrap::flags::Flags as clap_builder::derive::Args>::augment_args::DEFAULT_VALUE::{{closure}} () at flags.rs:110
#4  0x0347d7a8 in core::ops::function::FnOnce::call_once ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.72.0-src/library/core/src/ops/function.rs:250
#5  0x0347f29c in core::ops::function::FnOnce::call_once ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.72.0-src/library/core/src/ops/function.rs:250
#6  0x033f87c8 in once_cell::sync::Lazy<T,F>::force::{{closure}} ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/vendor/once_cell-1.12.0/src/lib.rs:1212
#7  0x033f8be0 in once_cell::sync::OnceCell<T>::get_or_init::{{closure}} ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/vendor/once_cell-1.12.0/src/lib.rs:1023
#8  0x0383c624 in once_cell::imp::OnceCell<T>::initialize::{{closure}} ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/vendor/once_cell-1.12.0/src/imp_std.rs:85
#9  0x03cdf5d8 in core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut ()
#10 0x03ce0d98 in once_cell::imp::initialize_or_wait ()
#11 0x0383c010 in once_cell::imp::OnceCell<T>::initialize ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/vendor/once_cell-1.12.0/src/imp_std.rs:81
#12 0x033f9880 in once_cell::sync::OnceCell<T>::get_or_try_init ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/vendor/once_cell-1.12.0/src/lib.rs:1063
#13 0x033f89b0 in once_cell::sync::OnceCell<T>::get_or_init ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/vendor/once_cell-1.12.0/src/lib.rs:1023
#14 0x033f86a8 in once_cell::sync::Lazy<T,F>::force ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/vendor/once_cell-1.12.0/src/lib.rs:1211
#15 0x033f8580 in <once_cell::sync::Lazy<T,F> as core::ops::deref::Deref>::deref ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/vendor/once_cell-1.12.0/src/lib.rs:1221
#16 0x03414ff4 in <bootstrap::flags::Flags as clap_builder::derive::Args>::augment_args () at flags.rs:110
#17 0x0340eee0 in <bootstrap::flags::Flags as clap_builder::derive::CommandFactory>::command () at flags.rs:33
#18 0x0383d784 in clap_builder::derive::Parser::parse_from ()
    at /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/vendor/clap_builder-4.2.4/src/derive.rs:52
#19 0x0340e7a4 in bootstrap::flags::Flags::parse () at flags.rs:199
#20 0x033d73c8 in bootstrap::config::Config::parse_inner () at config.rs:1117
#21 0x03681018 in bootstrap::config::Config::parse () at config.rs:1113
#22 0x03381578 in bootstrap::main () at bin/main.rs:20
(gdb) i reg
r0             0x0                 0
r1             0x0                 0
r2             0x0                 0
r3             0x1                 1
r4             0x0                 0
r5             0x60ed41e8          1626161640
r6             0x1                 1
r7             0x0                 0
r8             0x0                 0
r9             0x7ff64328          2146845480
r10            0x3d61425           64361509
r11            0x7ff642cc          2146845388
r12            0x7ff642d0          2146845392
sp             0x7ff642c0          0x7ff642c0
lr             0x3d2bf8c           64143244
pc             0x60d0fe74          0x60d0fe74 <_cpuset_isset+36>
cpsr           0x20030010          537067536
(gdb) x/i 0x60d0fe74
=> 0x60d0fe74 <_cpuset_isset+36>:   ldr     r3, [r1, r2, lsl #2]
(gdb) 

At least it gives a bit of clue about where to go looking for the
null pointer de-reference, so that's at least something...

Meanwhile, the arm64/9.0 build succeeded, and the sparc64/10.0_BETA
build appears to have passed this particular hurdle.

Regards,

- Havard