Should we compile and ship libraries with debug information whenever possible

compilercopyrightdebuggingproductivityrelease

There is considerable cost (and pain) for developers to debug external libraries due to the fact that many libraries are distributed in two editions: one with debug information, other without. The developer has to search and download debug files, and point the debugging environment to their location. This is often a painful and error-prone task. There is also a lot of work related to build and distribute those libraries.

At same time, the world changed in ways that make the "release" version (ie the version without debugging information) obsolete. For instance:

  • A modern runtime can efficiently strip debugging information, optimize on-the-fly and run the program at full speed. Examples are the JVM and JavaScript interpreters.
  • Open-source projects, or binaries that are not published outside the company, have no reason to be obfuscated. Also, given that many modern languages now support reflection, obfuscation by stripping debug information is very limited, if effective at all.
  • Disk space is high, disk performance (SDDs) is getting better and better, and network bandwidth is improving as well.

Please note that this question is limited to libraries. I'm 100% OK about distributing applications without debugging information, which is actually extremely important in the mobile world.

After a lot of trouble with .NET PDBs, and .class files without debugging information, I think we should evolve processes and tools into a world where the default is to compile and distribute libraries with full debug information, embedded in the binary (like .class files) if that's possible. After all, the only remote reason for not doing that is protecting copyrights (which doesn't apply to many scenarios).

Of course, the tools that pack applications should be smart enough to search and destroy every piece of embedded debugging information before publishing for download. This is based on the fact that end-users seldom debug applications.

Best Answer

It might also be a question for your lawyers.

A library (or an executable) compiled with debug info (e.g. in C++, on Linux, compiled with g++ -g2 -O2 into ELF format with DWARF debug info) contains a lot of [meta-]data which facilitates the reverse engineering of your code.

If you release that thing to outside clients, you expose some of your industrial/intellectual property to them (in particular all your data structures, the class hierarchy, the name of your files, classes, functions, variables, etc...). Decompilation of your code becomes much less difficult (even if it stays quite hard).

Also, the debug information takes a lot of space. That might have some cost (bandwidth, data volume) when deploying your software.

BTW, producing open source software facilitates even more your work, with the potential benefit that some outside contributor might slightly improve it.

If you can (i.e. you want and you are allowed to) release debug information, indeed it is simpler to release some binary (of your library or of your program) with debug information included in it (and not in a separate file). Notice that many compilers are able to optimize and still emit debug information (e.g. with GCC you can compile with both -g -O2 flags; the debug information is there, but is "approximate" because of optimizations).

Related Topic