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 <jing...@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 <gclay...@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 <ztur...@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 <gclay...@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 <jing...@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 <c...@remobjects.com> wrote: > >>>> > >>>> > >>>> > >>>> Op 2016-04-04 om 20:30 schreef Greg Clayton: > >>>>> > >>>>>> On Apr 4, 2016, at 11:24 AM, Zachary Turner <ztur...@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 > >>> > >> > > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
