[ObjectYAML][MachO] Encode export trie address as ULEB128, not as SLEB128
authorDaniel Rodríguez Troitiño <danielrodriguez@fb.com>
Tue, 4 Oct 2022 00:46:42 +0000 (17:46 -0700)
committerDaniel Rodríguez Troitiño <danielrodriguez@fb.com>
Tue, 4 Oct 2022 16:17:58 +0000 (09:17 -0700)
commit57bd11f047d040fb52520a0ae2bc74542099a162
treecd3733027f1cbecdc2d487c79d643029d6fe4ef5
parent54a4e9685d0110a28a88a40cf9e8d05a4ecdd631
[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
llvm/lib/ObjectYAML/MachOEmitter.cpp
llvm/test/ObjectYAML/MachO/export_trie.yaml