11–20 of 21 posts
Please Arch Linux developers: stop stripping all packages of debug symbols
Isn't it a common practice to strip, but keep them in separately published files that only contain symbols?
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…
I noticed that clang seems to be better at generating correct infos in such modes.
Otherwise I use GDB in "batch mode" to get a callstack triggered by raise(SIGTRAP):
> gdb -quiet --batch -ex run -ex backtrace --args $binary $@
It's frustrating when developers distribute binaries without debug information under the mistaken assumption that it's going to impact on performance. At a previous company I worked at we were using Scaleform (UI solution for games) and they refused to ship debug information with their release builds. I reported it as a bug and sent them links and information about how it wouldn't affect performance, but they still r…
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…
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?
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.
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…
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?
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.
The main pain point for me in that domain currently is the wrong results that backtrace() gives when optimizations are enabled. I noticed that clang seems to be better at generating correct infos in such modes. Otherwise I use GDB in "batch mode" to get a callstack triggered by raise(SIGTRAP): > gdb -quiet --batch -ex run -ex backtrace --args $binary $@
It's better than nothing, but consider using something like libunwind instead.
The main pain point for me in that domain currently is the wrong results that backtrace() gives when optimizations are enabled. I noticed that clang seems to be better at generating correct infos in such modes. Otherwise I use GDB in "batch mode" to get a callstack triggered by raise(SIGTRAP): > gdb -quiet --batch -ex run -ex backtrace --args $binary $@
backtrace(3) doesn't use or understand DWARF debug information at all — it's purely a machine stack (doesn't understand tail calls or inlined functions) and can only look up ELF symbols. It's better than nothing, but consider using something like libunwind instead.
The ultimate goal is to get a backtrace without debug symbol (in release) but I don't know any method to achieve that without instrumentation.
Earlier quoted context omitted.
backtrace(3) doesn't use or understand DWARF debug information at all — it's purely a machine stack (doesn't understand tail calls or inlined functions) and can only look up ELF symbols. It's better than nothing, but consider using something like libunwind instead.
Many thanks. I'll check it. The ultimate goal is to get a backtrace without debug symbol (in release) but I don't know any method to achieve that without instrumentation.
> For example, if you would only like accurate unwinding then you can retain only .debug_frame and .debug_line.