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

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

drodriguez marked an inline comment as done.
drodriguez added a comment.

In D134250#3803983 <https://reviews.llvm.org/D134250#3803983>, @beanz wrote:

> Amusingly the only documentation I'm aware of that documents the format of the export trie... is in a file you modified in this change: https://github.com/llvm/llvm-project/blob/main/llvm/tools/obj2yaml/macho2yaml.cpp#L473

😆  I think you wanted to use "As usual", and not "Amunsigly". Lacking format documentation seems to be a constant with Mach-O 😆

Do you happen to know if the contents of the newer `LC_DYLD_EXPORTS_TRIE` have the same format as the previous trie? It seems to me that they look very similar. I wonder if I can reuse a little bit of the code and improve this to have a more human-friendly dump (I will need to modify some code of the Object library first, which seems to not deal with this old place/new place duality).



================
Comment at: llvm/lib/ObjectYAML/MachOYAML.cpp:172
+  IO.mapOptional("ChainedFixups", LinkEditData.ChainedFixups);
+  IO.mapOptional("DyldExportsTrie", LinkEditData.ChainedFixups);
+  IO.mapOptional("DataInCode", LinkEditData.DataInCode);
----------------
pete wrote:
> Should this be LinkEditData.DyldExportsTrie?
Thanks. Good eyes. I did not realize that the initial yaml dump had the same values in both places.


================
Comment at: llvm/tools/obj2yaml/macho2yaml.cpp:648
+
+void MachODumper::dumpDyldExportsTrie(std::unique_ptr<MachOYAML::Object> &Y) {
+  MachOYAML::LinkEditData &LEData = Y->LinkEdit;
----------------
pete wrote:
> 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?
Thanks for the explanation. It clarifies why I could not get one with both `LC_DYLD_INFO` and `LC_DYLD_CHAINED_FIXUPS`. I was confuse why there was the design had two structures named almost the same ("exports trie" and a "dyld exports trie").

As you pointed out above, this was doing the wrong thing. I think autocomplete of `dyld…`  found `getDyldInfoExportsTrie` and I did not realize that I was looking for the wrong piece of the binary. I changed the code to find the LC and dump the contents directly.

This code also only deals with `LC_DYLD_EXPORTS_TRIE`, since it was the one we started having problems (for the problems see D133974). It seems that the code in `dumpExportsTrie` and `processExportNode` dump the other.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134250