Retain debug information in a separate file

[jan-auer]

This is intended to provide a fix for softprops/serverless-rust#49.

The current build script unconditionally invokes strip on the build output, which removes all debug information. There are two cases, in which debug information is desirable, however:

• The binary is built in debug mode. The developer likely intends to have debug information inside the binary.
• The binary is built in release mode with debug information enabled. The developer likely intends to build an optimized binary without debug information, but wants debug information in a separate companion file for offline debugging.

With this patch, debug information is retained in dev builds. Note that this makes the resulting binary significantly larger, but is more suitable for testing. In release builds, debug information is moved into bootstrap.debug next to bootstrap.zip. Developers can use this for debugging.

[softprops]

@jan-auer very neat (and thoughtful)!

[softprops]

@jan-auer I'm not super familiar with using rust with a debugger. How would I test this out?

[jan-auer]

@softprops Are you asking for how to verify that this setup works or how to use a debugger in general for Rust?

In debug builds, the easiest way to verify that debug information is available is to cause a panic and set RUST_BACKTRACE=1 on the environment. The stack trace should contain file names and line numbers.

On Linux, Rust's internal backtrace library cannot resolve debug information once it has been stripped into a separate file. The most basic way I can think of right now is to use gdb or lldb. With the GNU debuglink, DDB should be able to load the auxiliary file automatically. Once you set a breakpoint and ask for the stack trace, you should see file names and line numbers again.

[softprops]

That works for me. Thanks!

[maxcountryman]

The binary is built in release mode with debug information enabled. The developer likely intends to build an optimized binary without debug information, but wants debug information in a separate companion file for offline debugging.

It would be nice if this could somehow respect [profile.release] debug = true as defined in a crate's Cargo.toml, which I would think signals an optimized build with debug information is desired.

This would be nice for cases such as Sentry, where you might want the debug info in production while also releasing an optimized binary; it doesn't seem like the bootstrap.debug file is particularly useful there.

[softprops]

@jan-auer since this release I'm seeing objcopy: stvEI9YY: debuglink section already exists in built output. Is this expected. Again, sry I'm not super familiar with objcopy vs strip

[softprops]

@maxcountryman good tip!

[jan-auer]

It would be nice if this could somehow respect [profile.release] debug = true as defined in a crate's Cargo.toml, which I would think signals an optimized build with debug information is desired.

This is a little harder, as there are multiple ways to enable debug information in release builds. Another is just by exporting RUST_FLAGS=-g (iirc).

@jan-auer since this release I'm seeing objcopy: stvEI9YY: debuglink section already exists in built output. Is this expected. Again, sry I'm not super familiar with objcopy vs strip

Sorry, I might have missed this when testing. You can probably just remove the --add-debug-link line and see if the debug link is valid. I wasn't aware that the objcopy utility would automatically add a debug link.

[softprops]

no worries. I don't think it has a negative impact. I can follow up.