Reducing debug info for stack traces, while preserving for gdb

Iain Buclaw ibuclaw at gdcproject.org
Sat Dec 24 22:00:23 UTC 2022


Hi,

On Wednesday, 14 December 2022 at 22:23:49 UTC, Witold Baryluk 
wrote:>
> The bulk of information is in `.debug_info`. But I believe it 
> contains way more information than is really needed to just 
> produce line numbers.
>

You're observation is correct.  GDC uses libbacktrace to produce 
stack traces, and this indeed does traverse the `.debug_info` 
section in order to achieve its job.

https://github.com/gcc-mirror/gcc/blob/8ec139af5ea9657c7517c1483c7a577815bea48e/libbacktrace/dwarf.c#L2116-L2120


>
>
> I did inspect final binaries , and it is using DWARF version 5.
>
> I also tried `-gas-loc-support` , but no change.
>
> Using `-g1` makes stack traces work nicely, by making 
> `.debug_info` smaller, but then debugging in `gdb` is very 
> limited. One option would be to compile application twice, once 
> with `-g1` and once with `-g3`. But I really do not think this 
> is supported, or reliable, even if I enable deterministic 
> builds.
>

I'm not sure on this, I'd have to give it some thought.

> In one article ( 
> https://support.backtrace.io/hc/en-us/articles/360040105792-DWARF#RemovingDebugInformation )  I read that for C/C++ in GCC, it is enough to preserve only `.debug_frame` and `.debug_line` to get function, source filenames and line numbers. But that is not true for gdc and its stacktrace handler.
>

C++ stdlib doesn't give stack traces AFAIU, and if it does, it 
would be using libbacktrace too.  I guess then the article must 
be referring to the implementation of `execinfo.h` and/or 
`dladdr`.

Perhaps a run-time fallback could be added to gdc's stack trace 
support to use the `execinfo.h` backtrace functions if the 
`.debug_info` (or whatever platform equivalent) section does not 
exist.  From what I recall, execinfo is not quite as accurate as 
libbacktrace though.

Iain.


More information about the D.gnu mailing list