[all-commits] [llvm/llvm-project] 9e2497: [lld/mac] Fix function offset on 1st-level unwind ...

Nico Weber via All-commits all-commits at lists.llvm.org
Sun Jul 4 15:10:40 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9e24979d73f172258aac704638501b63e39028c4
      https://github.com/llvm/llvm-project/commit/9e24979d73f172258aac704638501b63e39028c4
  Author: Nico Weber <thakis at chromium.org>
  Date:   2021-07-04 (Sun, 04 Jul 2021)

  Changed paths:
    M lld/MachO/UnwindInfoSection.cpp
    M lld/test/MachO/compact-unwind.s

  Log Message:
  -----------
  [lld/mac] Fix function offset on 1st-level unwind table sentinel

Two bugs:
1. This tries to take the address of the last symbol plus the length
   of the last symbol. However, the sorted vector is cuPtrVector,
   not cuVector. Also, cuPtrVector has tombstone values removed
   and cuVector doesn't. If there was a stripped value at the end,
   the "last" element's value was UINT64_MAX, which meant the
   sentinel value was one less than the length of that "last"
   dead symbol.

2. We have to subtract in.header->addr. For 64-bit binaries that's
   (1 << 32) and functionAddress is 32-bit so this is a no-op, but
   for 32-bit binaries the sentinel's value was too large.

I believe this has no effect in practice since the first-level
binary search code in libunwind (in UnwindCursor.hpp) does:

    uint32_t low = 0;
    uint32_t high = sectionHeader.indexCount();
    uint32_t last = high - 1;
    while (low < high) {
      uint32_t mid = (low + high) / 2;
        if ((mid == last) ||
            (topIndex.functionOffset(mid + 1) > targetFunctionOffset)) {
          low = mid;
          break;
        } else {
        low = mid + 1;
      }

So the address of the last entry in the first-level table isn't really
checked -- except for the very end, but the check against `last` means
we just run the loop once more than necessary. But it makes `unwinddump` output
look less confusing, and it's what it looks was the intention here.

(No test since I can't think of a way to make FileCheck check that one
number is larger than another.)

Differential Revision: https://reviews.llvm.org/D105404




More information about the All-commits mailing list