[Lldb-commits] [PATCH] Invalidate process uid/gid command options on Windows

[Zachary Turner]

I guess approaching the question from a different angle.  Consider two
scenarios: 1) You run "platform process list" while connected to a target.
 2) You run "platform process list" while not connected to a target.  In
scenario #2, the only option is to display processes on the host.  In
scenario #1, does lldb currently display the processes on the host or the
target?  I suspect the host (I can't check because I only have a Windows
box, so I have no way to debug any kind of actual target yet).  So if this
is correct, then this entire command is basically a host only command.   So
maybe the validator could take one argument representing the host platform,
and one argument for the execution context.  It would then be up to each
validator's implementation to decide whether it cares about checking the
host, the execution context, or some combination of the two depending on
the command.


On Mon, Jul 7, 2014 at 10:51 AM, <jingham at apple.com> wrote:

> If there's no target, then we should consult the current platform - if
> nobody set a platform then that will default to the host platform.  Usually
> you get that from the target, so it would seem odd to pass that in
> separately, but maybe in this case that's okay to do.  Otherwise whoever
> would be passing an ExecutionContext to the validators could, in the case
> where there was no selected target, make up an empty target, set it to the
> current platform and pass that in to the validator.
>
> Jim
>
>
>
> > On Jul 3, 2014, at 10:00 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > So, with an ExecutionContext, everything is null if there's no target.
>  For example, I might not be attached to anything, but trying to list
> processes on the host in order to know what process to attach to.
> >
> > How to cleanly support all of these use cases?
> >
> >
> > On Thu, Jul 3, 2014 at 11:14 AM, <jingham at apple.com> wrote:
> > Again, the validator should take an execution context not an
> interpreter.  Some uses of commands, particularly HandleCommands used by
> breakpoint callbacks and the like, don't use the Command Interpreter's
> execution context, rather they are passed in the appropriate environment.
> >
> > Jim
> >
> > > On Jul 3, 2014, at 2:24 AM, Zachary Turner <zturner at google.com> wrote:
> > >
> > > This patch implements the core logic to invalidate command options
> based on the interpreter state, and uses this to invalidate uid/gid related
> options of the "platform process list" command on Windows.
> > >
> > > When an invalid option is specified for a command, an error message is
> printed that explains the reason that the option is invalid, and
> furthermore when the help of a command is printed, options which have
> runtime validity conditions display an abbreviated-condition string in
> square braces prior to the long description of the option.
> > >
> > > http://reviews.llvm.org/D4373
> > >
> > > Files:
> > >  include/lldb/Host/OptionParser.h
> > >  include/lldb/Interpreter/CommandInterpreter.h
> > >  include/lldb/Interpreter/CommandOptionValidators.h
> > >  include/lldb/Interpreter/Options.h
> > >  include/lldb/Target/TargetList.h
> > >  include/lldb/lldb-private-types.h
> > >  source/Commands/CommandObjectPlatform.cpp
> > >  source/Interpreter/Args.cpp
> > >  source/Interpreter/CMakeLists.txt
> > >  source/Interpreter/CommandOptionValidators.cpp
> > >  source/Interpreter/Options.cpp
> > > <D4373.11047.patch>_______________________________________________
> > > lldb-commits mailing list
> > > lldb-commits at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140707/2a5777d2/attachment.html>