Deterministic package files break lldb

[ehuss]

Problem
#8864 introduced deterministic packaging. One of the key aspects is that the mtime of every file is set to 0. Unfortunately, this seems to prevent lldb from reading the file. This means that stepping into dependencies from crates.io won't show any source information.

Arguably this is a bug in lldb. This does not seem to affect gdb. Unfortunately I feel like the likelyhood of fixing this in lldb is low (and even if it does get fixed, I imagine it would take years to trickle into Apple's release).

Steps

cargo new foo
cd foo
cargo package --allow-dirty
tar -xzvf target/package/foo-0.1.0.crate
cd foo-0.1.0
ls -al src   # verify that timestamp is Dec 31  1969 main.rs
cargo build
lldb target/debug/foo
b main.rs:2
run
######
# You should see output like this, notice there is no source information.
# Process 176294 launched: '/home/eric/Temp/foo/foo-0.1.0/target/debug/foo' (x86_64)
# Process 176294 stopped
# * thread #1, name = 'foo', stop reason = breakpoint 1.1
#     frame #0: 0x000055555555b9d4 foo`foo::main::h2ffdc3ce2a8b2165 at main.rs:2:5
quit

touch src/main.rs
cargo build
lldb target/debug/foo
b main.rs:2
run
######
# You should see output like this, notice we now have source!
# Process 176406 launched: '/home/eric/Temp/foo/foo-0.1.0/target/debug/foo' (x86_64)
# Process 176406 stopped
# * thread #1, name = 'foo', stop reason = breakpoint 1.1
#     frame #0: 0x000055555555b9d4 foo`foo::main::h2ffdc3ce2a8b2165 at main.rs:2:5
#    1    fn main() {
# -> 2        println!("Hello, world!");
#    3    }

Possible Solution(s)
I'm not sure. Cargo could set the timestamp of files when they are extracted. Would just need to be careful with #7590. I think setting all files to the same timestamp should be sufficient?

Notes

Output of cargo version: cargo 1.54.0-nightly (070e459 2021-05-11)

Seems to affect lldb on both macOS and Linux.
Linux: lldb version 10.0.0 and lldb version 11.0.0 and lldb version 12.0.1
macOS: lldb-1200.0.44.2 (Xcode 12.4 (12D4e))

[alexcrichton]

Wow nice find! This comparison in particular looks pretty suspcious.

I forgot that we preserved mtimes... In any case I think we should do two things to fix this:

• For all tarballs going foward, let's set the mtime to like Jan 1, 2000. Just something that's nonzero (even 1 would probably be fine)
• I'll update the tar crate to skip setting the mtime if the mtime is zero.

[alexcrichton]

Thinking more about this, I don't think that we can skip the zero mtime case. If we skip the zero mtime case then we run afoul of #7590 where we'd basically just ignore mtimes altogether. I've opened alexcrichton/tar-rs#250 to handle both points above which I think should fix this issue. New archives created by Cargo will have nonzero mtimes and older archives will start being extracted with an mtime of 1 instead of 0.

@ehuss mind reviewing that PR and the strategy here?