[all-commits] [llvm/llvm-project] a89e01: [lldb] Improve unwinding for discontinuous functio...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a89e01634fe2e6ce0b967ead24280b6693b523dc
      https://github.com/llvm/llvm-project/commit/a89e01634fe2e6ce0b967ead24280b6693b523dc
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2024-10-14 (Mon, 14 Oct 2024)

  Changed paths:
    M lldb/source/Commands/CommandObjectTarget.cpp
    M lldb/source/Symbol/UnwindTable.cpp
    A lldb/test/Shell/Unwind/Inputs/basic-block-sections-with-dwarf.s
    A lldb/test/Shell/Unwind/Inputs/linux-x86_64.yaml
    A lldb/test/Shell/Unwind/basic-block-sections-with-dwarf-static.test
    A lldb/test/Shell/Unwind/basic-block-sections-with-dwarf.test

  Log Message:
  -----------
  [lldb] Improve unwinding for discontinuous functions (#111409)

Currently, our unwinder assumes that the functions are continuous (or at
least, that there are no functions which are "in the middle" of other
functions). Neither of these assumptions is true for functions optimized
by tools like propeller and (probably) bolt.

While there are many things that go wrong for these functions, the
biggest damage is caused by the unwind plan caching code, which
currently takes the maximalist extent of the function and assumes that
the unwind plan we get for that is going to be valid for all code inside
that range. If a part of the function has been moved into a "cold"
section, then the range of the function can be many megabytes, meaning
that any function within that range will probably fail to unwind.

We end up with this maximalist range because the unwinder asks for the
Function object for its range. This is only one of the strategies for
determining the range, but it is the first one -- and also the most
incorrect one. The second choice would is asking the eh_frame section
for the range of the function, and this one returns something reasonable
here (the address range of the current function fragment) -- which it
does because each fragment gets its own eh_frame entry (it has to,
because they have to be continuous).

With this in mind, this patch moves the eh_frame (and debug_frame) to
the front of the queue. I think that preferring this range makes sense
because eh_frame is one of the unwind plans that we return, and some
others (augmented eh_frame) are based on it. In theory this could break
some functions, where the debug info and eh_frame disagree on the extent
of the function (and eh_frame is the one who's wrong), but I don't know
of any such scenarios.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications