Page MenuHomePhabricator

Move start-address finding to Target, implement fallback if main executable does not have a start address

Authored by jasonmolenda on Jul 17 2019, 5:04 PM.



On the upcoming version of macOS, 10.15 or Catalina, there are userlang kernel drivers ("DriverKit" processes) and one unique thing about a DriverKit main binary is that it has no start address load command in the same way that a normal user process binary has. lldb uses the entry address ("main") as a function address that is never called during the normal execution of the program, after the process has started, for doing inferior function calls. It creates a fake stack frame with "main" as the return address, puts a breakpoint on main, and uses that breakpoint hit to indicate that the function call completed successfully. Because DriverKit processes don't have a traditional main, lldb can't do inferior function calls.

Currently this is found in ThreadPlanCallFunction::ConstructorSetup - it finds the Target's main executable, asks for its entry address. This patch moves that code into a new Target::GetEntryPointAddress method which tries the main executable, but if that executable fails, steps through every other Module asking if there is an entry address for that module. The patch also changes ObjectFileMachO to look for the function _dyld_start in the dyld binary -- another function that is never called -- and uses that as a backup entry address function.

Testing this is a bit difficult - these DriverKit userland drivers are not launched like normal processes, we can't run a test DriverKit from the testsuite under lldb. I'm still thinking about this; to test this by hand I #if 0'ed out ObjectFileMachO's normal entry address logic (looking at LC_MAIN load command etc) so it had to fall back to the _dyld_start one.

Diff Detail


Event Timeline

jasonmolenda created this revision.Jul 17 2019, 5:04 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 17 2019, 5:04 PM
Herald added a subscriber: abidh. · View Herald Transcript

I wonder if we ought to allow target properties (target as an example) that are only for testing, so they don't print when you do settings list, etc. But the we could have some settings like a "target.testing.dont-read-LC_MAIN" and that would make it easy to automate your hand testing. Kind of like the "experimental" decorator, except you have to know they exist to use them...

Hm, that could be really helpful! I think I'd like to do that as a separate piece of work a little bit later, but I'll look at that.

This revision was not accepted when it landed; it landed in state Needs Review.Jul 18 2019, 1:56 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 18 2019, 1:56 PM