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.
