search

taiki-e / upload-rust-binary-action

GitHub Action for building and uploading Rust binary to GitHub Releases.
Apache License 2.0
247 stars 22 forks source link

Split debuginfos in addition to stripping #48

Open brancz opened 1 year ago

brancz commented 1 year ago

Since this action does all: compiling, stripping, and uploading, it's currently not possible to retain debuginfos in a separate file, since they're just stripped away immediately after building. Debuginfos are important for debuggers and profilers to work though so it would be nice if there was some way to enable keeping them.

Would you be open to in addition to stripping adding an object copy that first extracts debuginfos? For example here:

objcopy --only-keep-debug "${target_dir}/${bin_exe}" "${target_dir}/${bin_exe}.debug"
taiki-e commented 1 year ago

Is the actual request here to add an option to support split-debuginfo? Or is it to add an option to not strip?

In the former case, specifying split-debuginfo in the profile and using the include/asset option would probably already work. In the latter case, this action should already respect it if you explicitly set strip to false in the profile.

In any case, I'm open to adding an option to make it easier. However, as for split-debuginfo, considering cross that doesn't propagate environment variables to cargo by default, users will probably need to specify the option in the profile anyway.

brancz commented 1 year ago

The problem with split-debuginfo is that the format of debuginfos it produces is very different from those that are included in the binary. This is because split-debuginfo produces dwp dwarf package files which are easy to produce but not supported by many tools. Whereas when including debuginfos in the binary with debug = true they are produced the same way as Linux distributions publish on debuginfod servers.

taiki-e commented 1 year ago

So the actual request is the latter (add an option to not strip)?

brancz commented 1 year ago

I think that's generally a useful thing to have, but often people want minimal production binaries but still keep the debuginfos somehow for using with profiling or debugging (I happen to need them for profiling). So I think both an option to not stripping at all, and an option that when stripping to retain the debuginfos in a separate file.

brancz commented 1 year ago

If you're generally open to this, I'd be happy to draft something up.

taiki-e commented 1 year ago

I would accept PRs to implement them.