[Lldb-commits] [PATCH] D82378: [lldb/Unwind] Use eh_frame plan directly when it doesn't need to be augmented

Tue Jun 23 10:10:32 PDT 2020

jankratochvil added a comment.

In D82378#2109330 <https://reviews.llvm.org/D82378#2109330>, @labath wrote:

> Now this situation is not actually handled by lldb's "augmenter", so the example somewhat shaky, but it does show that there are gaps in clang/llvm modelling of unwind info.

Good to know but ... I do not see how is this `stdcall` unwinding bug related to this issue whether to use `.eh_frame` or not - `UnwindAssembly_x86::AugmentUnwindPlanFromCallSite` cannot verify any `.eh_frame` is 100% valid.

> As for the DW_AT_producer idea, the main gotcha I see there is that eh/debug_frame is supposed to be usable even without the rest of the debug info.

Producer is also recorded in `.gnu.build.attributes` which is in the main binary (not in external `.debug` info):

  $ annocheck --enable-notes /bin/bash
  Notes: Range: 0x304e0 .. 0xe22e9.
    [O] Tool: running gcc 10.1.1 20200507
  Notes: Range: 0x311f0 .. 0xe26a5.
    [O] Tool: running gcc 10.1.1 20200507

  $ readelf -Wn /bin/bash
  Displaying notes found in: .gnu.build.attributes
    Owner                                Data size        Description
    GA$<tool>running gcc 10.1.1 20200507 0x00000000       OPEN        Applies to region from 0x304e0 to 0xe22e9
    GA$<tool>running gcc 10.1.1 20200507 0x00000000       OPEN        Applies to region from 0x311f0 to 0xe26a5

Although in fact one does not need to parse the notes at all as if there exist such annobin notes one can already guarantee the compiler is new enough.

> the need for a fallback makes the idea less appealing.

Fallback without installed external debuginfo would not work much but a fallback for old binaries still without annobin notes is not so bad IMO.

> The other problem with that is that we would actually have to gather information about which compilers report the unwind info correctly.

non-clang/non-gcc compilers can contribute whitelist entries themselves. Such whitelisting would not regress the existing behavior, it would only further improve the whitelisted clang+gcc compilers.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82378/new/

https://reviews.llvm.org/D82378