[all-commits] [llvm/llvm-project] f512b9: [lldb/Utility] Improve error_code->Status conversion

[Pavel Labath via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: f512b978b0ebd09be08d879acb4feb7846370cd5
      https://github.com/llvm/llvm-project/commit/f512b978b0ebd09be08d879acb4feb7846370cd5
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2020-04-23 (Thu, 23 Apr 2020)

  Changed paths:
    M lldb/source/Utility/Status.cpp
    M lldb/unittests/Utility/StatusTest.cpp

  Log Message:
  -----------
  [lldb/Utility] Improve error_code->Status conversion

Both entities have the notion of error "namespaces". Map the errno
namespace correctly.


  Commit: 7cfa74fc6948cc1969244a4e800de6a728951897
      https://github.com/llvm/llvm-project/commit/7cfa74fc6948cc1969244a4e800de6a728951897
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2020-04-23 (Thu, 23 Apr 2020)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h
    M lldb/test/Shell/SymbolFile/DWARF/DW_AT_loclists_base.s
    M lldb/test/Shell/SymbolFile/DWARF/debug_loc.s

  Log Message:
  -----------
  [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables

Summary:
The code in DWARFCompileUnit::BuildAddressRangeTable tries hard to avoid
relying on DW_AT_low/high_pc for compile unit range information, and
this logic is a big cause of llvm/lldb divergence in the lowest layers
of dwarf parsing code.

The implicit assumption in that code is that this information (as opposed to
DW_AT_ranges) is unreliable. However, I have not been able to verify
that assumption. It is definitely not true for all present-day
compilers (gcc, clang, icc), and it was also not the case for the
historic compilers that I have been able to get a hold of (thanks Matt
Godbolt).

All compiler included in my research either produced correct
DW_AT_ranges or .debug_aranges entries, or they produced no DW_AT_hi/lo
pc at all. The detailed findings are:
- gcc >= 4.4: produces DW_AT_ranges and .debug_aranges
- 4.1 <= gcc < 4.4: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
  present. The upper version range here is uncertain as godbolt.org does
  not have intermediate versions.
- gcc < 4.1: no versions on godbolt.org
- clang >= 3.5: produces DW_AT_ranges, and (optionally) .debug_aranges
- 3.4 <= clang < 3.5: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
  present.
- clang <= 3.3: no DW_AT_ranges, no DW_AT_high_pc, no .debug_aranges
- icc >= 16.0.1: produces DW_AT_ranges
- icc < 16.0.1: no functional versions on godbolt.org (some are present
  but fail to compile)

Based on this analysis, I believe it is safe to start trusting
DW_AT_low/high_pc information in dwarf as well as remove the code for
manually reconstructing range information by traversing the DIE
structure, and just keep the line table fallback. The only compilers
where this will change behavior are pre-3.4 clangs, which are almost 7
years old now. However, the functionality should remain unchanged
because we will be able to reconstruct this information from the line
table, which seems to be needed for some line-tables-only scenarios
anyway (haven't researched this too much, but at least some compilers
seem to emit DW_AT_ranges even in these situations).

In addition, benchmarks showed that for these compilers computing the
ranges via line tables is noticably faster than doing so via the DIE
tree.

Other advantages include simplifying the code base, removing some
untested code (the only test changes are recent tests with overly
reduced synthetic dwarf), and increasing llvm convergence.

Tags: #lldb

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


Compare: https://github.com/llvm/llvm-project/compare/d8a4a9916199...7cfa74fc6948