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

[jingham at apple.com]

> On Jul 7, 2014, at 11:06 AM, Zachary Turner <zturner at google.com> wrote:
> 
> 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.

You can do "platform select" independently of creating a target.  You can also connect to the platform server on a remote platform (that's a job debugserver can do, and presumably llgs at some point.) to do things like list processes.

So you still need to check the current platform, it might not be the host platform.

Jim


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