Bug 22081 – DWARF v5 support is utterly broken - 'illegal instruction' when throwing exceptions

GCC 11 defaults to emitting DWARF v5 (at least with reasonably recent binutils apparently). If a D executable contains any DWARF 5 line-number programs (e.g., from linked-in C(++) object files), the utterly broken druntime code (introduced by https://github.com/dlang/druntime/pull/3189) hits an assert(0) when trying to resolve file/line infos for the exception backtrace. So EH is totally broken. See https://forum.dlang.org/post/[email protected] for an exemplary gdb backtrace. I've looked at the DWARF 5 spec, and the druntime code is absolutely wrong in many aspects. It surely hasn't been tested even *once*. Can be reproduced with LDC and `ldc2 -g -dwarf-version=5 foo.d && ./foo`, for a foo.d throwing an exception.

@kinke created dlang/druntime pull request #3502 "Fix Issue 22081 - Utterly broken DWARF v5 support" fixing this issue: - Fix Issue 22081 - Utterly broken DWARF v5 support This has actually been tested to work with LDC, fixing the `assert(0)` and **numerous** terrible issues of #3189 after looking at the DWARF v5 spec. LLVM apparently puts all directory/file name strings into the new .debug_line_str section (DW_FORM_line_strp form code, one of various encoding options); reading the strings from there would require mmapping that section too, not just the .debug_line one. So at least with LLVM, *all* source file paths (of according DWARF v5 line-number programs) in the exception backtrace string currently show up as `<unknown dir>/<unknown file>`. https://github.com/dlang/druntime/pull/3502

dlang/druntime pull request #3502 "[stable] Fix Issue 22081 - Utterly broken DWARF v5 support" was merged into stable: - 5589d61648e9ee1ece36437dfbcaf24651a79f36 by Martin Kinkelin: Fix Issue 22081 - Utterly broken DWARF v5 support This has actually been tested to work with LDC, fixing the `assert(0)` and **numerous** terrible issues of #3189 after looking at the DWARF v5 spec (section 6.2.4). LLVM apparently puts all directory/file name strings into the new .debug_line_str section (DW_FORM_line_strp form code, one of various encoding options); reading the strings from there would require mmapping that section too, not just the .debug_line one. So at least with LLVM, *all* source file paths (of according DWARF v5 line-number programs) in the exception backtrace string currently show up as `<unknown dir>/<unknown file>`. https://github.com/dlang/druntime/pull/3502

dlang/druntime pull request #3515 "merge stable" was merged into master: - 414316556aa95fa5b3b03a558479ecd4ccacb86e by Martin Kinkelin: Fix Issue 22081 - Utterly broken DWARF v5 support This has actually been tested to work with LDC, fixing the `assert(0)` and **numerous** terrible issues of #3189 after looking at the DWARF v5 spec (section 6.2.4). LLVM apparently puts all directory/file name strings into the new .debug_line_str section (DW_FORM_line_strp form code, one of various encoding options); reading the strings from there would require mmapping that section too, not just the .debug_line one. So at least with LLVM, *all* source file paths (of according DWARF v5 line-number programs) in the exception backtrace string currently show up as `<unknown dir>/<unknown file>`. - 56bfaaf03c9ff8ea3a1c9bcf41259c941cccef26 by Martin Kinkelin: Fix Issue 22081 - Utterly broken DWARF v5 support This has actually been tested to work with LDC, fixing the `assert(0)` and **numerous** terrible issues of #3189 after looking at the DWARF v5 spec (section 6.2.4). LLVM apparently puts all directory/file name strings into the new .debug_line_str section (DW_FORM_line_strp form code, one of various encoding options); reading the strings from there would require mmapping that section too, not just the .debug_line one. So at least with LLVM, *all* source file paths (of according DWARF v5 line-number programs) in the exception backtrace string currently show up as `<unknown dir>/<unknown file>`. https://github.com/dlang/druntime/pull/3515