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 <ztur...@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 <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
