Run iOS apps in an lldb session #77
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Getting an lldb session running in the simulator is a two-step process:
1. The binary itself must be launched from within lldb in order to
capture the processes output streams.
2. Once the binary is launched, the app must then be "launched" from
within the simulator. This doesn't actually create a new process,
but instead brings the app into the foreground of the simulator, and
is analogous to tapping on the app icon.
Because of the order of these steps, the `xcrun simctl launch` command
has to be run from with the lldb session.
Because lldb won't normally accept further commands after `process
launch`, we use the `-s` argument to have the app pause just after
starting (like stopping at a breakpoint). However, running `xcrun simctl
launch` at this very early stage (before `main` has even executed)
causes a separate instance of the app to start up in the simulator.
In order to work around this we set a breakpoint on `-[UIApplication _run]`,
which is early enough that the application hasn't actually started yet,
but after `UIApplicationMain` has set everything up and started the main
run loop. Breaking here is a safe place to shell out to `xcrun simctl
launch`, which will no longer start a separte process because the app is
already "running".
The other quirk is that in order to feed commands to lldb we need to use
the `-s` option, which requires a file. So the launch script is written
to a temporary file first so that it can be passed to lldb. Bash process
substitution may also work (e.g., `<(cat "$script")`).
|
Related conversation: #76 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Getting an lldb session running in the simulator is a two-step process:
Because of the order of these steps, the
xcrun simctl launchcommand has to be run from with the lldb session.Because lldb won't normally accept further commands after
process launch, we use the-sargument to have the app pause just after starting (like stopping at a breakpoint). However, runningxcrun simctl launchat this very early stage (beforemainhas even executed) causes a separate instance of the app to start up in the simulator.In order to work around this we set a breakpoint on
-[UIApplication _run], which is early enough that the application hasn't actually started yet, but afterUIApplicationMainhas set everything up and started the main run loop. Breaking here is a safe place to shell out toxcrun simctl launch, which will no longer start a separte process because the app is already "running".The other quirk is that in order to feed commands to lldb we need to use the
-soption, which requires a file. So the launch script is written to a temporary file first so that it can be passed to lldb. Bash process substitution may also work (e.g.,<(cat "$script")).