[lldb-dev] break on exceptions/windows

[Greg Clayton via lldb-dev]

FYI: there is already a way for process plug-ins to add their own commands. If we look at ProcessGDBRemote:

class CommandObjectMultiwordProcessGDBRemote : public CommandObjectMultiword
{
public:
    CommandObjectMultiwordProcessGDBRemote (CommandInterpreter &interpreter) :
        CommandObjectMultiword (interpreter,
                                "process plugin",
                                "A set of commands for operating on a ProcessGDBRemote process.",
                                "process plugin <subcommand> [<subcommand-options>]")
    {
        LoadSubCommand ("packet", CommandObjectSP (new CommandObjectProcessGDBRemotePacket    (interpreter)));
    }

    ~CommandObjectMultiwordProcessGDBRemote ()
    {
    }
};

CommandObject *
ProcessGDBRemote::GetPluginCommandObject()
{
    if (!m_command_sp)
        m_command_sp.reset (new CommandObjectMultiwordProcessGDBRemote (GetTarget().GetDebugger().GetCommandInterpreter()));
    return m_command_sp.get();
}


These commands and then accessed by:

(lldb) process plugin ...

So if there is something that can't be easily fit into an agnostic implementation, you could fall back onto this.

I don't think this is one of those cases. We should be able to come up with something that can abstract this well.

Greg


> 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
> >>>
> >>
> >
>