Hi Jim, Thanks for this, I’m too tired to take it in now, I’ll look at it in more detail tomorrow. Off the top though, a couple of questions:
1. The “breakpoint_filters.py” file. Do I have to add this to my XCode Project? 2. The Commands: > (lldb) break set -E objc > (lldb) commmand script import ~/breakpoint_filters.py > (lldb) break command add -F breakpoint_filters.reject_by_parent_name Do I need to type this in each time I open XCode? Is there a way of having it auto-magically run when the Project is opened? Thanks a lot, All the Best Dave >> I had thought that there was a option to only trigger the breakpoint if the >> exception is uncaught, which in this case it *is* caught, but that option >> seems to have disappeared. > > Not in lldb or gdb before it. I have various bugs to add filtering by thrown > object, and figuring out whether/where the exception will get caught, but > that's still work to do... > > However, what you really want to do is check the objc_exception_throw's > caller and if it (or something above it depending on how exactly this > happens) is CoreFoundation, then you tell the breakpoint to continue. > > This isn't that hard to do using the Python breakpoint commands. Make a > Python file somewhere (say breakpoint_filters.py) > > $ cat ~/breakpoint_filters.py > def reject_by_parent_name (frame, bp_loc, dict): > caller = frame.parent > if caller.IsValid(): > if "BadFunc" in caller.name: > return False > return True > > Then run your project, for instance do: > > (lldb) break set -E objc > (lldb) commmand script import ~/breakpoint_filters.py > (lldb) break command add -F breakpoint_filters.reject_by_parent_name > > Then in this trivial case, if the caller of your breakpoint has "BadFunc" in > the name, the breakpoint will auto-continue. > > You can keep calling parent to trace up the stack however high you need to go > to find the CoreFoundation caller you are trying to block. Or you can get > the frames array from: > > frames = frame.thread.frames > > then frames[0] is the youngest frame, frames[1] its caller, and so on. > > You can also check the shared library for the code in a given frame: > > frame.module.file.basename > > will return the base name (e.g. CoreFoundation) for the binary where the code > from the current frame lives. That might be handier than having to check a > particular function name. > > Xcode doesn't support adding Python breakpoint commands to breakpoints yet, > so you either have to set the breakpoint by hand (shown above) or look it up > with "break list" and add the command to it after the fact. > > One convenient trick to set up these sorts of things is to set a breakpoint > in Xcode early on (e.g. main) and add the commands given above to that > breakpoint and auto-continue. > > Hope this helps, > > Jim > > >> >> I know less about LLDB than you do, and as it’s not in a separate framework >> file I don’t think it can be done anyway. >> >> Cheers >> Dave >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Xcode-users mailing list (Xcode-users@lists.apple.com >> <mailto:Xcode-users@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/xcode-users/jingham%40apple.com >> <https://lists.apple.com/mailman/options/xcode-users/jingham%40apple.com> >> >> This email sent to jing...@apple.com <mailto:jing...@apple.com>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
