> On Jul 7, 2014, at 11:06 AM, Zachary Turner <ztur...@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, <jing...@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 <ztur...@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, <jing...@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 <ztur...@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@cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits > > > > > > _______________________________________________ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits