[PATCH] D134250: [ObjectYAML] Support chained fixups, dyld exports trie, data in code

Pete Cooper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 20 14:02:29 PDT 2022


pete added inline comments.


================
Comment at: llvm/lib/ObjectYAML/MachOYAML.cpp:172
+  IO.mapOptional("ChainedFixups", LinkEditData.ChainedFixups);
+  IO.mapOptional("DyldExportsTrie", LinkEditData.ChainedFixups);
+  IO.mapOptional("DataInCode", LinkEditData.DataInCode);
----------------
Should this be LinkEditData.DyldExportsTrie?


================
Comment at: llvm/tools/obj2yaml/macho2yaml.cpp:648
+
+void MachODumper::dumpDyldExportsTrie(std::unique_ptr<MachOYAML::Object> &Y) {
+  MachOYAML::LinkEditData &LEData = Y->LinkEdit;
----------------
So the exports trie is a little weird.  It used to live in the LC_DYLD_INFO/LC_DYLD_INFO_ONLY along with bind opcodes.  If the binary is using opcode based fixups, then it is required that the trie come from there, not the LC_DYLD_EXPORTS_TRIE.

If the binary is newer, and uses LC_DYLD_CHAINED_FIXUPS then it is required that the export trie (if there is one) comes from the LC_DYLD_EXPORTS_TRIE.

I don't know if that impacts this code or not, but roughly i'd expect the export trie to be dumped either next to the bind opcodes as part of the LC_DYLD_INFO, or next to the chained fixups as a LC_DYLD_EXPORTS_TRIE.  Does this dump method handle both those cases, or just the LC_DYLD_EXPORTS_TRIE case?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134250/new/

https://reviews.llvm.org/D134250



More information about the llvm-commits mailing list