[all-commits] [llvm/llvm-project] d865f3: [lldb] Parse DWARF CFI for discontinuous functions...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d865f32fe820f543f0a53bfeba08774f2c270589
      https://github.com/llvm/llvm-project/commit/d865f32fe820f543f0a53bfeba08774f2c270589
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2025-05-07 (Wed, 07 May 2025)

  Changed paths:
    M lldb/include/lldb/Symbol/DWARFCallFrameInfo.h
    M lldb/source/Symbol/DWARFCallFrameInfo.cpp
    M lldb/source/Symbol/FuncUnwinders.cpp
    M lldb/source/Symbol/UnwindTable.cpp
    M lldb/source/Target/RegisterContextUnwind.cpp
    M lldb/test/Shell/Unwind/Inputs/basic-block-sections-with-dwarf.s
    M lldb/test/Shell/Unwind/basic-block-sections-with-dwarf-static.test
    M lldb/unittests/Symbol/TestDWARFCallFrameInfo.cpp

  Log Message:
  -----------
  [lldb] Parse DWARF CFI for discontinuous functions (#137006)

This patch uses the previously build infrastructure to parse multiple
FDE entries into a single unwind plan. There is one catch though: we
parse only one FDE entry per unwind range. This is not fully correct
because lldb coalesces adjecant address ranges, which means that
something that originally looked like two separate address ranges (and
two FDE entries) may get merged into one because if the linker decides
to put the two ranges next to each other. In this case, we will ignore
the second FDE entry.

It would be more correct to try to parse another entry when the one we
found turns out to be short, but I'm not doing this (yet), because:
- this is how we've done things so far (although, monolithic functions
are unlikely to have more than one FDE entry)
- in cases where we don't have debug info or (full) symbol tables, we
can end up with "symbols" which appear to span many megabytes
(potentially, the whole module). If we tried to fill short FDE entries,
we could end up parsing the entire eh_frame section in a single go. In a
way, this would be more correct, but it would also probably be very
slow.

I haven't quite decided what to do about this case yet, though it's not
particularly likely to happen in the "production" cases as typically the
functions are split into two parts (hot/cold) instead of one part per
basic block.



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