user2655474
user2655474

Reputation: 171

Is it possible to use a breakpoint to discover next code executed

This may seem a little backwards, but I'm in a huge iOS application, and trying to understand where the visual interface elements (views, controls) are calling into the code. Much of the views are built dynamically unfortunately, so it's not as simple as just going to Interface Builder and looking at Target/Actions and IBOutlets.

Generally, people use breakpoints by setting them ahead of time in predetermined locations in code, and then waiting for them to be hit.

Well, I am wondering if it's possible to set a breakpoint in such a way (maybe through LLDB?) that essentially says... "hey, I don't know what's going to execute next, but whatever that is, break there."

This would be extremely useful for me in figuring out where the views and controls enter the code.

Upvotes: 1

Views: 182

Answers (2)

Matt
Matt

Reputation: 1586

What bneely suggested is a good way to get an overall picture of what is going on. If you want a simple way to quickly get to some code and know a little bit about what base class is involved, you can use symbolic break points.

For example, say I want to get to the code for some UIButton event callback. I can add the following symbolic breakpoint: '-[NSObject performSelector:withObject:withObject:]'. (yes two withObjects). This will probably stop in a some assembly code. Luckily, the selector is in a register, so with gdb: info registers or lldb register read should display the selector. Then it's a matter of cmd+shift+o (open quickly), paste in the selector and hit enter on the (hopefully single) result, or judge from the context.

Another useful one might be: '-[UIControl sendActionsForControlEvents:]'

In addition, a good way to find UI code is to search the project for the text that the UI control displays.

If all else fails, hopefully contributors to the code base followed good naming conventions and organized the files well.

EDIT:

If the selector doesn't show up at first, and instead you get something like '_controlTouchBegan:withEvent', then simply continue until you hit the relevant selector.

Upvotes: 2

bneely
bneely

Reputation: 9093

You can use the Instruments application. From Xcode, choose Product > Profile, then select Time Profiler under the iOS Simulator > CPU options. Press the Profile button. Make the app do whatever it is you want to analyze, then press the Stop button at the top left of the Instruments window. You will get a collapsed view of the call tree, which you can expand (tip: option-click on a disclosure triangle to expand all of a symbol's descendants at once) and browse to follow the execution path.

Upvotes: 2

Related Questions