Create separate `.debug` file for debug symbols

[richardwhiuk]

Currently, there are two options when it comes to debug symbols:

• By default, they aren't included in the release profile. If they are included they can be stripped. This means that you end up with a small binary, but with no debug symbols.

• Alternatively, Cargo can be configured to keep the debug symbols in the release profile, and they get left in the binary. This means that the binary is fairly large (e.g. it can be more than ten times as big), but the binary can be debugged.

This change adds a third option, and adds the --separate-debug-symbols option to cargo deb. In this mode, the debug symbols will be copied to a separate .debug file before being stripped out.

This debug file will be placed under /usr/lib/debug which will automatically be picked up by GDB. This means the debug symbols won't inflate the size of binary in memory, but will be available on demand.

[kornelski]

Thank you for the PR. It looks like a great change.

Could this be the default behavior? Are there any downsides to this other than the increased .deb size?

[richardwhiuk]

@kornelski It could be the default behavior - our main motivation was to not change the behavior of the tool as is. I'm happy to change it if you think that's the right way to go.

Note, I think the README is slightly misleading. It currently says:

Debug symbols are stripped from the main binary by default. To keep debug symbols, either set [profile.release] debug = true in Cargo.toml or run cargo deb --no-strip.

which implies that if you pass --no-strip on it's own then you will get debug symbols. I think that's wrong - in order to get debug symbols currently you need to tell both Cargo to keep them in the release profile, and cargo-deb not to strip them (or with this change keep them separate). I'm happy to tweak that as well.

Note, a purist solution might be to produce foo-dbg.deb or .ddeb binary, but that's significantly more complicated to create and ship. Also note, that you can index /usr/lib/debug by the ID in the .gnu_debuglink section of the ELF file for GDB (see https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html) but rust doesn't include that section in the ELF file, likely because the linker is provided by LLVM and not GCC.

[kornelski]

One more thing — the strip_binaries loop has now grown to be a bit of spaghetti with nested and_then and duplicated error handling. Could you reorganize it, e.g. move some of it to a separate function?