Add a make flag to produce a seperate debug archive

[kevingranade]

Summary

None

Purpose of change

Split debugging data into separate files.
This also reduces link time and memory utilization.
It also seems to decrease ccache disk utilization locally.

Describe the solution

Add a flag to the Makefile that splits debug data to .dwo files instead of writing them to .o files, and then bundles them into a .dwp file.
This .dwp file will need to be archived and such in CI so we can retrieve it for testing.
For testing and for build speed benefits I'm trying out enabling it on most CI builds.

Testing

Produces .dwo and .dwp files locally.
Launched cataclysm and cata_test under gdb, able to print full backtraces, step, print variable names, etc.
You shouldn't need to do anything to have this work on local builds.

Additional context

This will need some more follow up to bundle the new archive from CI.

[akrieger]

Segmentation fault (core dumped)

That's not promising lol.

https://github.com/CleverRaven/Cataclysm-DDA/actions/runs/9245036514/job/25431113711#step:14:1147

[akrieger]

cc1plus: note: ‘-gsplit-dwarf’ is not supported with LTO, disabling

Well there's your problem.

[kevingranade]

Damn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88389

So -flto looks like fundamentally incompatible with -gsplit-dwarf
and I doubt it's worth supporting it for the fat part of the objects.

Need to test on more recent gcc in case they reversed this. LTO is the #1 place where this helps in principle.

[kevingranade]

Clang doesn't seem happy about split-dwarf plus LTO either: https://discourse.llvm.org/t/lto-thinlto-and-split-dwarf/70927
probably just cancel split-dwarf if the LTO flag is set for now, there might be some kind of solution somewhere but no need to block getting this going for all the non-LTO builds first.

[akrieger]

https://github.com/CleverRaven/Cataclysm-DDA/actions/runs/9248288152/job/25561768627?pr=74067#step:14:533

Seems like it's still OOMing on some builds, in the dwp step.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.