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.