Calling everything "catch" is a bit too much of a catch-all though (excuse the pun).<br><br>I like the idea of every command being able to have a platform specific sub command, similar to gregs suggested "platform break set".<br><br>But I think you need a way to make commands themselves platform specific so that entire commands or subcommands could exist only for certain platforms.  There's plenty of commands i want to implement on Windows that have no analogue anywhere else, so at some level i still think we need a way to have dynamic commands and options that only show up for a given platform <br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 4, 2016 at 2:40 PM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Jim<br>
<br>
<br>
> On Apr 4, 2016, at 2:28 PM, Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> (lldb) platform breakpoint set ...<br>
><br>
> 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.<br>
><br>
><br>
><br>
>> On Apr 4, 2016, at 1:27 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
>><br>
>> 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<br>
>><br>
>> break set windows --exc-code=0xC0000005<br>
>><br>
>> 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.<br>
>><br>
>> On Mon, Apr 4, 2016 at 1:18 PM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
>> 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.<br>
>><br>
>> Greg<br>
>><br>
>>> On Apr 4, 2016, at 11:41 AM, Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
>>><br>
>>> 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:<br>
>>><br>
>>> Error<br>
>>> Platform::SetPlatformBreakpoint(lldb_private::Target *target, const char *data);<br>
>>><br>
>>> Then this can have any meaning that it needs to.  The other way to structure this is:<br>
>>><br>
>>> break set -P -key "KEY" -value "VALUE"<br>
>>><br>
>>> Jim<br>
>>><br>
>>><br>
>>><br>
>>>> On Apr 4, 2016, at 11:36 AM, Carlo Kok <<a href="mailto:ck@remobjects.com" target="_blank">ck@remobjects.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Op 2016-04-04 om 20:30 schreef Greg Clayton:<br>
>>>>><br>
>>>>>> On Apr 4, 2016, at 11:24 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
>>>>>><br>
>>>>>> It seems like we already have some precedent for conditional command arguments.  For example:<br>
>>>>>><br>
>>>>>> (lldb) help platform process list<br>
>>>>>> ...<br>
>>>>>>      -u <unsigned-integer> ( --uid <unsigned-integer> )<br>
>>>>>>           [POSIX] Find processes that have a matching user ID.<br>
>>>>>><br>
>>>>>> 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:<br>
>>>>>><br>
>>>>>> (lldb) help break set<br>
>>>>>> ...<br>
>>>>>>      --code <hex-integer> ( --code <hex-integer> )<br>
>>>>>>           [Windows Target] Break when the exception with code <code> is raised.<br>
>>>>>><br>
>>>>>> How to plumb this to the ProcessWindows plugin is an open question, but should be mostly mechanical.<br>
>>>>><br>
>>>>> This is like my suggestion of:<br>
>>>>><br>
>>>>> (lldb) breakpoint set --exception-code 0x40010005<br>
>>>>><br>
>>>>> The code can be passed to the current Platform along with the current target:<br>
>>>>><br>
>>>>> Error Platform::SetExceptionBreakpointWithExceptionCode (lldb_private::Target *target, uint64_t exception_code);<br>
>>>>><br>
>>>>> The process can be extracted from the target when the breakpoint needs to be resolved.<br>
>>>>><br>
>>>>><br>
>>>><br>
>>>> There should be a way then to do a "break on every exception", instead of just 1 specific code.<br>
>>>><br>
>>>> and some way for the api to get the payload (which can have a variable number of parameters)<br>
>>>><br>
>>>> --<br>
>>>> Carlo Kok<br>
>>>> RemObjects Software<br>
>>><br>
>><br>
><br>
<br>
</blockquote></div>