[lldb-dev] break on exceptions/windows

[Greg Clayton via lldb-dev]

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
>