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.