Split debuginfos in addition to stripping

[brancz]

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]

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]

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]

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

[brancz]

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]

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

[taiki-e]

I would accept PRs to implement them.