Separate debug symbols file on Linux

[mcarans]

Split Dwarf or objcopy extraction result in a "slim" binary and a separate debug file.

For the former, build with -gsplit-dwarf then run dwp to create the master symbol file.

[LW-archlinux]

Please clarify for which type of build this would be used.

Systemwide installs (distro packages) typically use compiler flags to add debug symbols, put them in separate debug packages that become available through [url=https://sourceware.org/elfutils/Debuginfod.html]debuginfod[/url] .
gdb has full support for debuginfod.

[mcarans]

I think this could be used for all builds. We already build with symbols then strip them for certain builds. This stripping would not be necessary.

From what I understand, putting -gsplit-dwarf as a compiler flag should make builds faster by splitting out the symbols during compilation. The binary produced will be small and its performance is unaffected so there don't seem to be any disadvantages of using it on all builds.

I don't much about this topic, only what AI tells me. Is this an issue you would like to look at?

[oocube]

In https://bb.oolite.space/viewtopic.php?p=304812#p304812 the use case was laid out:
Get better debug information from users. Why would we not add this to all builds?

The benefit on the other hand is visible to me: Java or C# always run as managed code and provide stack traces for any exceptions thrown. It helps vastly for supporting the product.

[LW-archlinux]

So this is not about adding dwarf symbols to linux builds but about adding debug symbols to all oolite builds ?

That makes perfect sense.

The typical way to create debug files on linux is to add the symbols to the executables during compuile and strip them out after compilation has finished.

In the past (say 5+ years ago) the stripped symbols were thrown away , nowadays they're put in separate files .
For distro packages this is done by the package manager, an IDE may also do this for you. For command line builds it may be needed to run strip (and objcopy?) manually .

Keep in mind that debug symbols take a lot of space: on archlinux libreoffice-fresh has an installed size of 417 MiB, libreoffice-fresh-debug is 1249 MiB or 3 times as large.

I'll have to look up details, but there are several ways to get debug symbols and not all of them can coexist.
limiting ourselves to just dwarf symbols may not be a smart choice.

[oocube]

Oolite should be less code than LibreOffice, but let's find out how much bigger our builds will grow and then take an educated decision.

[LW-archlinux]

ATM debug build is broken, see #592, so I can't give numbers.

I have asked for help on arch forum thread and got useful answers.

objcopy does the heavy lifting and takes care of splitting debug symbols to separate files.
GCC & Clang doc indicate using -g0 , -g1 , g2 will let the compiler determine which debug info to add depending on the platform it's run on.
It's also possible to give a list of specific formats, but if none of them are suitable for the platform no debug will be added.

My experience with other games/applications imdicates building with debug symbols > stripping them to separate files does not have performance disadvantages for users compared with binaries build without debug symbols.

We may have to switch the buildsystem to allow adding debug symbols for all targets instead of having separate debug targets.

[mcarans]

My impression from AI is that building and then stripping the symbols is the old approach while the more modern one is to compile with -gsplit-dwarf then package the .dwo files into a single .dwp which acts much the same as the .debug file from the old approach. From what I gather, regardless of which approach, underneath DWARF symbols are used because it's the gold standard on Linux (whereas MS use PDB on Windows).

AI says: ".dwp file serves the same purpose as a traditional .debug file created by objcopy (keeping symbols separate from the binary)...GDB and LLDB are designed to look for a .dwp file automatically if they see a binary was built with "Split DWARF." If you name it correctly (e.g., program.dwp next to program), the debugger just works...For large projects, a .dwp file is often significantly smaller than a standard .debug file containing the same level of detail."

Feature	Standard -g + objcopy	-gsplit-dwarf + dwp
Linker Memory Use	High: Linker merges all debug data (can be several GBs).	Low: Linker only handles code/data; ignores debug info.
Incremental Link Time	Slow: Linker rewrites huge binaries on every change.	Very Fast: Linker only rewrites the tiny executable code.
Deduplication	Low: Redundant type info is often duplicated in the ELF.	High: Uses "Type Unit" deduplication to merge shared headers.
Debugger Load Speed	Standard: GDB maps large sections of the ELF.	Optimized: Uses a "Package Index" for faster, lazy lookups.
CI/CD Resource Friendly	No: Requires large runners/RAM to avoid OOM crashes.	Yes: Runs easily on small, cheap instances.
Post-Build Step	objcopy --only-keep-debug	dwp -e
Final Result	1 Stripped Bin + 1 .debug file	1 Stripped Bin + 1 .dwp file

Maybe you can ask about the two approaches on the Arch forum?