[jcelerier]

> They have a huge program, it is 2GiB minus epsilon of .text,

but the article says 25+GiB including debug symbols, in a single binary?

also, I appreciate your enthusiasm in assuming that because some people do something in an organization, it is applied consistently everywhere. Hell, if it were microsoft other departments would try to shoot down the "debug tooling optimization" dpt

[loeg]

Yes, the 25GB figure in the article is basically irrelevant to the 2GB .text section concern. Most ELF files that size are 95%+ debuginfo.

[jcelerier]

yes and that's what I'm saying, I find it crazy to not split the debug info out. At least on my machine it really makes a noticeable difference of load time if I load a binary which is ~2GB with debug info in or the same binary which is ~100MB with debug info out.

[Mic92]

Doesn't make any difference in practice. The debug info is never mapped into memory by the loader. This only matters if you want to store the two separate i.e lazy load debug symbols if needed.

[jcelerier]

this is just not true. I just tried with one of my binaries which is 3.2G unstripped, and 150MB-ish stripped. Unstripped takes 23 seconds until the window shows up, stripped takes ~a second

[jeffbee]

There is something wacky going on with your system, or the program is written in a way that makes it traverse the debug info if it is present. What program is it?

For example I can imagine desktop operating system antivirus/integrity checks having this effect.

[jeffbee]

ELF is just a container format and you can put literally anything into one of its sections. Whether the DWARF sections are in "the binary" or in another named file is really quite beside the point.