[dgwynne]

Solaris developed another solution, specifically CTF (Compressed Type Format). CTF stores data types and function signatures rather than full debug info, and is therefore much smaller than the DWARF information it is derived from.

The entire Solaris system is built with CTF enabled, which is used to support their debuggers and dtrace. Other systems have adopted it too. OpenBSD is moving to use CTF, and has enabled it's use in the kernels and debuggers on some architecture.

To get a sense of the size difference, DWARF information for a sparc64 kernel is about 27 megabytes. The CTF information derived from it is 473 kilobytes.

[valleyer]

It sounds like CTF (which I'm admittedly only peripherally aware of through exposure to dtrace) is not really a viable replacement for most DWARF use cases then, right? Why is the size comparison valid?

[wkz]

Function boundaries, arguments and data types will get you a long way in my experience. Sure there are times when you need to look at local variables in the middle of a function etc, but half of those times DWARF won't have the register information anyway. Remember the use-case here is production, your code will be optimized.

So you'll still end up disassembling the thing to figure out which register to look at. And you might as well do that on the unstripped binary on your development box. For embedded targets at least, that's a small price to pay for a size reduction of that magnitude.

[dgwynne]

I can't think of a reason not to ship DWARF except that it is big. Is there any other reason?

CTF is obviously less capable than DWARF, but it is small enough to ship by default and in my experience it is Good Enough(tm) for most debugging needs.