Debug Information Is Huge and What to Do About It

Re:Debug Information Is Huge and What to Do About It by mabynogy on Tuesday October 31, 2017 @02:35AM (#15591459)

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 $@

[ Parent | on HN ]

Re:Debug Information Is Huge and What to Do About It by loeg on Tuesday October 31, 2017 @02:58PM (#15595645)

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.

[ Parent | on HN ]

Re:Debug Information Is Huge and What to Do About It by mabynogy on Tuesday October 31, 2017 @04:19PM (#15596206)

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.

[ Parent | on HN ]

Re:Debug Information Is Huge and What to Do About It by loeg on Tuesday October 31, 2017 @04:33PM (#15596297)

You need some debug information to get accurate backtraces. But you can discard the rest of the debug information that you don't need. The article actually mentions this a little bit near the end, starting around:

> For example, if you would only like accurate unwinding then you can retain only .debug_frame and .debug_line.

[ Parent | on HN ]