> On Apr 26, 2016, at 1:54 PM, Dave <d...@looktowindward.com> wrote:
> 
> 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?

No, it just needs to be some place you can find it on the file system.  LLDB 
doesn't know about Xcode's build variables, so there's no way to tell lldb 
about it in a "project relative" manner (i.e. $PROJECT_DIR/Python/...)

> 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?
> 

You need to run these commands when the debugging session starts, not when the 
project is opened.  I suggested below putting an auto-continue breakpoint on 
main and inserting the commands given above into the Actions of that breakpoint.

Jim


> 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)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/xcode-users/jingham%40apple.com
>>> 
>>> This email sent to 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

Reply via email to