[all-commits] [llvm/llvm-project] 57bd11: [ObjectYAML][MachO] Encode export trie address as ...

[Daniel Rodríguez Troitiño via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 57bd11f047d040fb52520a0ae2bc74542099a162
      https://github.com/llvm/llvm-project/commit/57bd11f047d040fb52520a0ae2bc74542099a162
  Author: Daniel Rodríguez Troitiño <danielrodriguez at fb.com>
  Date:   2022-10-04 (Tue, 04 Oct 2022)

  Changed paths:
    M llvm/lib/ObjectYAML/MachOEmitter.cpp
    M llvm/test/ObjectYAML/MachO/export_trie.yaml

  Log Message:
  -----------
  [ObjectYAML][MachO] Encode export trie address as ULEB128, not as SLEB128

The `dumpExportEntry` was dumping everything using signed LEB128, but
the format seems to use unsigned LEB128. This can be cross-checked with
the implementation in MachOObjectFile.cpp, the implementation in LLD's
ExportTrie.cpp, and the implementation in macho2yaml.cpp, which all use
ULEB128 functions..

The difference is only apparent when encoding some values with specific
bit patterns (bit active in the 7th, 14th, ... bits of the binary). The
encoding was not always creating problems in the resulting binaries
because if the extra byte was part of the padding, the result of
decoding it as ULEB128 is the same as decoding as SLEB128, however, the
code of MachOObjectFile.cpp (used by llvm-objdump) checks the buffer
decoding position against the reported length, which triggered an error.

Modified a test that used an address with this pattern (0x3FA0, the 14th
bit is active), to show that a round trip still produces the same
results, and added a check using llvm-objdump to use their extra checks
to verify this implementation.

Reviewed By: pete

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