I'm trying to get a debugger to stop at a breakpoint when my rust program panics. I understand the recommendation to be to break on the rust_panic() function, but that's not working for me. Does anyone have any experience with this (or have an alternative)?

I'm on aarch64, I've tried both darwin and NixOS linux (via VM) both using nixpkgs cargo, rustc, lldb and gdb packages.

I've tried both rust-lldb and rust-gdb, neither is able to find the function and neither hit the breakpoint:

$ rust-lldb target/debug/delme
...
(lldb) b rust_panic
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 1612 launched: '/home/builder/delme/target/debug/delme' (aarch64)

thread 'main' panicked at src/main.rs:2:5:
Hello, world!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Process 1612 exited with status = 101 (0x00000065)

$ rust-gdb target/debug/delme
(gdb) b rust_panic
Function "rust_panic" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_panic) pending.
(gdb) r
Starting program: /home/builder/delme/target/debug/delme
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/gydncjm02ww60x9gamkhfwj3f34g3g8m-glibc-2.40-66/lib/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
Hello, world!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 1670) exited with code 0145]

$ cat src/main.rs
fn main() {
    panic!("panic called");
}

I'm trying to get a debugger to stop at a breakpoint when my rust program panics. I understand the recommendation to be to break on the rust_panic() function, but that's not working for me. Does anyone have any experience with this (or have an alternative)?

I'm on aarch64, I've tried both darwin and NixOS linux (via VM) both using nixpkgs cargo, rustc, lldb and gdb packages.

I've tried both rust-lldb and rust-gdb, neither is able to find the function and neither hit the breakpoint:

$ rust-lldb target/debug/delme
...
(lldb) b rust_panic
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 1612 launched: '/home/builder/delme/target/debug/delme' (aarch64)

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Process 1612 exited with status = 101 (0x00000065)

$ rust-gdb target/debug/delme
(gdb) b rust_panic
Function "rust_panic" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_panic) pending.
(gdb) r
Starting program: /home/builder/delme/target/debug/delme
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/gydncjm02ww60x9gamkhfwj3f34g3g8m-glibc-2.40-66/lib/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 1670) exited with code 0145]

$ cat src/main.rs
fn main() {
    panic!("panic called");
}

I'm trying to get a debugger to stop at a breakpoint when my rust program panics. I understand the recommendation to be to break on the rust_panic() function, but that's not working for me. Does anyone have any experience with this (or have an alternative)?

I'm on aarch64, I've tried both darwin and NixOS linux (via VM) both using nixpkgs cargo, rustc, lldb and gdb packages.

I've tried both rust-lldb and rust-gdb, neither is able to find the function and neither hit the breakpoint:

$ rust-lldb target/debug/delme
...
(lldb) b rust_panic
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 1612 launched: '/home/builder/delme/target/debug/delme' (aarch64)

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Process 1612 exited with status = 101 (0x00000065)

$ rust-gdb target/debug/delme
...
(gdb) b rust_panic
Function "rust_panic" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_panic) pending.
(gdb) r
Starting program: /home/builder/delme/target/debug/delme
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/gydncjm02ww60x9gamkhfwj3f34g3g8m-glibc-2.40-66/lib/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 1670) exited with code 0145]

$ cat src/main.rs
fn main() {
    panic!("panic called");
}

Good question...
I think this is it?

$ readlink -f /nix/var/nix/profiles/per-user/root/channels
/nix/store/in3n7rsk9rkhdfzsba2kfl1hzv13xbn3-nixos-25.11.20250708.9b008d6

(gdb) b rust_panic
Breakpoint 1 at 0x30ff4

(gdb) b rust_panic
Function "rust_panic" not defined.

Aha! As suggested
rbreak rust_panic worked for me in gdb (no joy with the suggested b s -r rust_panic in lldb, though).

Still that works well for my purposes. Thank you!

It looks like I just needed to use br s -r rust_panic (not b) in lldb and that works just fine.

Thank you both!

Oh, I was wrong about cargoDepsName not being used, I just misremembered. The important thing is: it no longer affects the hash. The old fetchCargoTarball implementation generated a tarball that had a directory name inside it dependent on the name of the package.
Now, with fetchCargoVendor, we no longer care about the names, the only thing that matters now is the exact contents of the Cargo.lock file: if anything changes in it, the hash will have to be regenerated.
This is because the Cargo.lock is copied into the FOD for later validation.
So, because the Cargo.lock file usually contains the version of the package, even if no deps were changed, the changed version value would lead to a new hash.

If we removed the Cargo.lock integrity check (where it checks if cargoDeps's Cargo.lock and src's Cargo.lock match), we'd no longer have to copy Cargo.lock into our FOD, so we'd only get a new hash if the dependency list changed.
This is not worth it compared to the integrity check, which is pretty important.