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