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