[lldb-dev] break on exceptions/windows

[Jim Ingham via lldb-dev]

"catch" would be for stopping on any process life-cycle events that aren't watchpoints or breakpoints (thread creation, spawning, etc are other examples.)  That seems quite well-defined to me.  And I like that the ways you can stop a program are not scattered throughout the command set.  By putting them under the catch heading, it will be much easier to find the capability if you didn't know that lldb could do that thing already.  Also, anything that stops the process is going to have a shared set of options, ignore count, commands, conditions and the like.  Even with the option groups managing these is some work, and it makes sense to centralize them.

Jim



> On Apr 4, 2016, at 2:53 PM, Zachary Turner <zturner at google.com> wrote:
> 
> Calling everything "catch" is a bit too much of a catch-all though (excuse the pun).
> 
> I like the idea of every command being able to have a platform specific sub command, similar to gregs suggested "platform break set".
> 
> 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 
> On Mon, Apr 4, 2016 at 2:40 PM Jim Ingham <jingham at apple.com> wrote:
> 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
> >>>
> >>
> >
>