Add -gsplit-dwarf to LTO build to cut memory utilization in linker #73812
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This will break debugging for this build for now, but it's currently failing so ehhhh...
Summary
None
Purpose of change
Some chatter on discord brought some build failures like https://github.com/CleverRaven/Cataclysm-DDA/actions/runs/9078930225/job/24950004752#step:14:746 to my attention, looks like memory exhaustion?
Attempted to avoid overlapping linker invocations in #73793 but that didn't do it.
Describe the solution
This passes a flag to the compiler (in github LTO builds only) to output debugging data to a separate file instead of to the .o file.
As a result, at link time the linker doesn't have to load and process that (massive) debug data and doesn't consume all the memory on the system.
Describe alternatives you've considered
There are various overhauls we could look into, but the debug data really is absolutely dominating memoy usage, so I think this is the way to go.
Testing
I ran the build locally using the same build arguments and a similar gcc version (mine: g++ (Ubuntu 9.4.0-1ubuntu1
20.04.2) 9.4.0, CI: g++-9 (Ubuntu 9.5.0-1ubuntu122.04) 9.5.0) as in the failing CI job.Before this change:
39.46user 12.12system 1:08.21elapsed 75%CPU (0avgtext+0avgdata 9189096maxresident)k
After this change:
7.80user 1.81system 0:09.89elapsed 97%CPU (0avgtext+0avgdata 1950676maxresident)k
The final test will be if the CI job breaks, but I'm very optomistic.
Additional context
This will break debugging for now since we aren't archiving and storing the debug data, but I think that's a better state to be in temporally than all the builds failing...
This article outlines what the whole process looks like: https://www.tweag.io/blog/2023-11-23-debug-fission/
Once we have that working, I suspect we'll want to switch all the CI builds over to this.