[all-commits] [llvm/llvm-project] 1e7292: [dsymutil] dsymutil produces broken lines info (pr...

[avl-llvm via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1e72920c8859771c03177623ad7519543d78eb7d
      https://github.com/llvm/llvm-project/commit/1e72920c8859771c03177623ad7519543d78eb7d
  Author: Alexey Lapshin <a.v.lapshin at mail.ru>
  Date:   2023-02-03 (Fri, 03 Feb 2023)

  Changed paths:
    M llvm/include/llvm/ADT/AddressRanges.h
    M llvm/include/llvm/DWARFLinker/DWARFLinkerCompileUnit.h
    M llvm/lib/DWARFLinker/DWARFLinker.cpp
    M llvm/lib/DWARFLinker/DWARFStreamer.cpp
    R llvm/lib/Support/AddressRanges.cpp
    M llvm/lib/Support/CMakeLists.txt
    M llvm/unittests/Support/AddressRangeTest.cpp

  Log Message:
  -----------
  [dsymutil] dsymutil produces broken lines info (probably) with LTO on mac

This patch fixes #60307 issue. The 8bb4451 introduces the possibility
to unite overlapped or adjacent address ranges to keep address ranges
in an unambiguous state. The AddressRangesMap is used to normalize
address ranges. The AddressRangesMap keeps address ranges and the value
of the relocated address. For intersected range, it creates a united
range that keeps the last inserted mapping value. The same for adjusted ranges.
While it is OK to use the last inserted mapping value for intersected ranges
(as there is no way how to resolve ambiguity) It is not OK to use the
last inserted value for adjacent address ranges. Currently, two following
address ranges are united into a single one:

{0,24,17e685c} {24,d8,55afe20} -> {0,d8,55afe20}

To avoid the problem, the AddressRangesMap should not unite adjacent address ranges
with different relocated addresses. Instead, it should leave adjacent address ranges
as separate ranges. So, the ranges should look like this:

{0,24,17e685c} {24,d8,55afe20}

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