This patch builds upon Jonas’ D132432 and aims to support symbols printing of a MH_FILESET MachO within llvm-nm. Currently llvm-nm returns “no symbols” for a fileset; as a result, discerning the presence of symbols within MachO entries may require manual inspection of the binary. One concern is that, among other things, this might inadvertently lead to the improper assumption that symbols may have been stripped (as LC_SYMTAB of main MachO has no symbols). This patch addresses this issue by establishing whether symbols actually exist or not within each MachO entry.
One possible implementation is to specialize dumpSymbolNamesFromObject function to encompass fileset handling as well. While it may be slightly suboptimal to retain the entire MachO in memory for each LC_FILESET_ENTRY, this ensures accurate MachO parsing, let us extend MachOObjectFile constructor to include just an offset that locates each MachO entry from the file's start, and it makes the patch as non-invasive as possible. Also, this would be exceptionally done only for a specific type of MachO. Note that the MachO would still need to be parsed (at least) twice, once to determine the MachO type, and again to locate the LC_SYMTAB within the entry.
The test is a simple mock MH_FILESET binary, generated from an iOS kernelcache, and trimmed so as to preserve one load command (a LC_FILESET_ENTRY), another LC within a MachO entry (a LC_SYMTAB), and the actual symbol table.
Why is the ifdef necessary? At first I thought the layout of the struct is different for 32-bit vs 64-bit targets but looking at loader.h I don't see any immediate evidence of that. Either way, changing the layout based on a compile-time constant/host property seems almost guaranteed to be wrong.