CentOS 7's rpmbuild can't handle debuginfo generated by Rust 1.50.0

[Arnavion]

Full repro and steps in rust-150-centos7.tar.gz. It's just a minimal bin crate with an RPM specfile that can be used with rpmbuild

To summarize, when CentOS 7's rpmbuild tries to extract the debuginfo from the binary to build the debuginfo package, it fails with:

...

cargo build --release
   Compiling foo v0.1.0 (/root/rpmbuild/BUILD/foo-1.0.0)
    Finished release [optimized] target(s) in 0.42s
install -D target/release/foo /root/rpmbuild/BUILDROOT/foo-1.0.0-1.x86_64/usr/bin/foo
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 /root/rpmbuild/BUILD/foo-1.0.0
extracting debug info from /root/rpmbuild/BUILDROOT/foo-1.0.0-1.x86_64/usr/bin/foo
/usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character
error: Bad exit status from /var/tmp/rpm-tmp.y1gaix (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.y1gaix (%install)

This is new with 1.50.0. It works fine with 1.49.0. Web search reveals https://bugzilla.redhat.com/show_bug.cgi?id=304121 as an example of where a source file path had an extra / that triggered this. I'm not sure what the reason is here.

Meta

Happens with both stable:

rustc 1.50.0 (cb75ad5db 2021-02-10)
binary: rustc
commit-hash: cb75ad5db02783e8b0222fee363c5f63f7e2cf5b
commit-date: 2021-02-10
host: x86_64-unknown-linux-gnu
release: 1.50.0

... and latest nightly:

rustc 1.52.0-nightly (07194ffcd 2021-02-10)
binary: rustc
commit-hash: 07194ffcd25b0871ce560b9f702e52db27ac9f77
commit-date: 2021-02-10
host: x86_64-unknown-linux-gnu
release: 1.52.0-nightly
LLVM version: 11.0.1

[Arnavion]

gdb -ex 'info func' -ex 'quit' ~/rpmbuild/BUILD/foo-1.0.0/target/release/foo | head -n 20

I suspect the problem might be due to this:

1.49.0:

All defined functions:

File library/std/src/../../backtrace/src/symbolize/mod.rs:
void _$LT$std..backtrace_rs..symbolize..SymbolName$u20$as$u20$core..fmt..Display$GT$::fmt::h1143a5884a698316();

File library/std/src/error.rs:
void _$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$dyn$u20$std..error..Error$u2b$core..marker..Sync$u2b$core..marker..Send$GT$$GT$..from..StringError$u20$as$u20$core..fmt..Debug$GT$::fmt::h8a62620ad0eef22d();
void _$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$dyn$u20$std..error..Error$u2b$core..marker..Sync$u2b$core..marker..Send$GT$$GT$..from..StringError$u20$as$u20$core..fmt..Display$GT$::fmt::h26d5b531480c1782();
void _$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$dyn$u20$std..error..Error$u2b$core..marker..Sync$u2b$core..marker..Send$GT$$GT$..from..StringError$u20$as$u20$std..error..Error$GT$::description::h715b772c2476d5fa();

1.50.0:

All defined functions:

File /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b//library/std/src/ffi/c_str.rs:
void _$LT$$RF$$u5b$u8$u5d$$u20$as$u20$std..ffi..c_str..CString..new..SpecIntoVec$GT$::into_vec::hf52a3b1666f80653();

File /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b//library/std/src/../../backtrace/src/symbolize/mod.rs:
void _$LT$std..backtrace_rs..symbolize..SymbolName$u20$as$u20$core..fmt..Display$GT$::fmt::h133dca60de4a708f();

File /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b//library/std/src/error.rs:
void _$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$dyn$u20$std..error..Error$u2b$core..marker..Sync$u2b$core..marker..Send$GT$$GT$..from..StringError$u20$as$u20$core..fmt..Debug$GT$::fmt::h7cdb755c343b6d82();

The //library in every filename might be the reason.

[Alexendoo]

Appears to be since #77117

[Arnavion]

Seems to have been fixed in 1.52.0, and is still fixed as of 1.54.0. 1.51.0 was the last release with the issue.