Page MenuHomePhabricator

Add support for a "main bin spec" LC_NOTE for standalone/firmware corefile binaries in MachO corefiles

Authored by jasonmolenda on Sep 25 2020, 1:21 AM.



This patch is primarily to ProcessMachCore to correctly load a firmware/standalone main binary in a corefile which is using the "main bin spec" LC_NOTE. There's already support for this for a "kern ver str" LC_NOTE that includes a UUID to load, this patch extends that to the other LC_NOTE and also sets the load address on the binary it locates to 0 (no-slide) as a default loading. I also stopped an unnecessary scan over the corefile looking for user-process dyld or kernel binaries once I'd already gotten one of these two LC_NOTEs.

I also modified ObjectFile::GetCorefileMainBinaryInfo to pass up the type of binary that was specified, which was in the "main bin spec" but not returned previously.

The test case is based on the one I wrote earlier for test/API/macosx/lc-note/kern-ver-str. It adds the ability to write both types of LC_NOTEs (kern ver str, main bin spec) and compiles two binaries (with random UUIDs). It creates a that recognizes the two UUIDs and points to the correct binaries/dSYMs, creates corefiles using the tool it built earlier, and runs lldb against the corefiles to confirm that the binaries are loaded correctly. It only runs on macOS x86_64 systems for now.

I'm not sure there's anyone who's really interested in reviewing this one; ProcessMachCore is my back yard in the codebase :) but I'm open to any comments or suggestions, naturally.

Diff Detail

Event Timeline

jasonmolenda created this revision.Sep 25 2020, 1:21 AM
jasonmolenda requested review of this revision.Sep 25 2020, 1:21 AM
JDevlieghere added inline comments.Sep 25 2020, 8:46 AM



/// <


It seems like this could be outlined into a little static helper function. Something along the lines of

BinaryType GetBinaryType(uint32_t binspec_type);

Maybe have a little lambda for the two bodies to reduce the duplication?


This does not look clang-formatted 🤐

Thanks for the feedback!


I don't feel strongly, but all of the "main bin spec" specific knowledge is centralized here in GetCorefileMainBinaryInfo, and converting the constant values this LC_NOTE uses for binary type into the enumerated values seems best kept local to this area.


Yeah, it's not great - but we're checking them in opposite order in the duplicated blocks, so I could make a lambda that did both, but it would need to take an arg about which to prefer and wouldn't be that much better I think.


oh my how did that happen.

This revision was not accepted when it landed; it landed in state Needs Review.Sep 25 2020, 3:19 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.