[lldb-dev] break on exceptions/windows

[Jim Ingham via lldb-dev]

If we're going this far, then we should just add a "catch" command, and have the platforms be able to add "catchable" things.  For instance, you could catch shared library loads, you could catch fork & exec, maybe IPC message sends and Windows exceptions.  Seems like they fit better in this model than as breakpoints.

Jim


> On Apr 4, 2016, at 2:28 PM, Greg Clayton <gclayton at apple.com> wrote:
> 
> We could add a "platform breakpoint set" command as a new stand alone breakpoint mechanism and avoid messing with the "breakpoint set" command at all. 
> 
> (lldb) platform breakpoint set ...
> 
> This would be passed to the current lldb_private::Platform plug-in for it to parse as needed. Each platform can have their own options that are completely custom.
> 
> 
> 
>> On Apr 4, 2016, at 1:27 PM, Zachary Turner <zturner at google.com> wrote:
>> 
>> Another option would be to have sub-sub commands.  Already when you mix so many options together, lots of the options don't make sense with each other.  What about
>> 
>> break set windows --exc-code=0xC0000005
>> 
>> This way all the windows specific stuff is wrapped up behind another subcommand, and you don't have to worry about consistency with other platforms' interfaces.
>> 
>> On Mon, Apr 4, 2016 at 1:18 PM Greg Clayton <gclayton at apple.com> wrote:
>> I really would rather avoid the key/value thing. I prefer the --exception-name and --exception-code and have the platform handle it. Seems cleaner.
>> 
>> Greg
>> 
>>> On Apr 4, 2016, at 11:41 AM, Jim Ingham <jingham at apple.com> wrote:
>>> 
>>> Yes, that's why I prefer a more abstract command interface than trying to be too specific about some abstract breakpoint.  So you'd just have:
>>> 
>>> Error
>>> Platform::SetPlatformBreakpoint(lldb_private::Target *target, const char *data);
>>> 
>>> Then this can have any meaning that it needs to.  The other way to structure this is:
>>> 
>>> break set -P -key "KEY" -value "VALUE"
>>> 
>>> Jim
>>> 
>>> 
>>> 
>>>> On Apr 4, 2016, at 11:36 AM, Carlo Kok <ck at remobjects.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> Op 2016-04-04 om 20:30 schreef Greg Clayton:
>>>>> 
>>>>>> On Apr 4, 2016, at 11:24 AM, Zachary Turner <zturner at google.com> wrote:
>>>>>> 
>>>>>> It seems like we already have some precedent for conditional command arguments.  For example:
>>>>>> 
>>>>>> (lldb) help platform process list
>>>>>> ...
>>>>>>      -u <unsigned-integer> ( --uid <unsigned-integer> )
>>>>>>           [POSIX] Find processes that have a matching user ID.
>>>>>> 
>>>>>> So on Windows this argument doesn't make sense.  Could we make an argument that is conditional on the *target* rather than the host?  Then, for example, you could have something like this:
>>>>>> 
>>>>>> (lldb) help break set
>>>>>> ...
>>>>>>      --code <hex-integer> ( --code <hex-integer> )
>>>>>>           [Windows Target] Break when the exception with code <code> is raised.
>>>>>> 
>>>>>> How to plumb this to the ProcessWindows plugin is an open question, but should be mostly mechanical.
>>>>> 
>>>>> This is like my suggestion of:
>>>>> 
>>>>> (lldb) breakpoint set --exception-code 0x40010005
>>>>> 
>>>>> The code can be passed to the current Platform along with the current target:
>>>>> 
>>>>> Error Platform::SetExceptionBreakpointWithExceptionCode (lldb_private::Target *target, uint64_t exception_code);
>>>>> 
>>>>> The process can be extracted from the target when the breakpoint needs to be resolved.
>>>>> 
>>>>> 
>>>> 
>>>> There should be a way then to do a "break on every exception", instead of just 1 specific code.
>>>> 
>>>> and some way for the api to get the payload (which can have a variable number of parameters)
>>>> 
>>>> --
>>>> Carlo Kok
>>>> RemObjects Software
>>> 
>> 
>