[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