[lldb-dev] Native windows debugging support

[jingham at apple.com]

> On Jul 2, 2014, at 5:35 PM, Zachary Turner <zturner at google.com> wrote:
> 
> Ok, I'll think about this approach some more.  It's funny that I'm of the opposite mind when it comes to the dependent help text.  As I would only ever be interested in seeing help for the selected target.  Would it be ok to add an option to help (for example "help -t") that hides options not relevant to the current target?

That seems fine to me.  If we had some tool that did "extract all the help text for all the targets and organize them into something with a table of contents and an index" I probably wouldn't feel so strongly about this.  But since the online help is currently the only source for this information I don't want to make it state-dependent...

Jim

> 
> 
> 
> 
> On Wed, Jul 2, 2014 at 5:17 PM, <jingham at apple.com> wrote:
> 
> > On Jul 2, 2014, at 4:53 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > On Wed, Jul 2, 2014 at 4:36 PM, <jingham at apple.com> wrote:
> >
> > Then the way command objects work is that their options are baked into the object handed to the command interpreter when they are added to the interpreter.  There's one command object for a given command name registered at startup.  I'm not sure how excited I am about swapping these things in and out as the currently selected Platform/Target/Process changes.  For instance, if you could very well be running a command for with TargetA currently selected in the main lldb interpreter, and at the same time the process in TargetB could hit a breakpoint and want to run some commands for its breakpoint action...  It would be a pain to juggle that sort of thing...  It would be much simpler to keep all the options in one command object, and have the context in which the command is running determine the validity of the commands options.
> >
> > What about attaching a (possibly different) CommandInterpreter to each Platform object?  They could differ arbitrarily.  So if TargetA hits a breakpoint followed by TargetB, we would just go through each Target's attached interpreter, and everything should "just work".
> 
> I have a bad feeling about this, it seems like adding some tricky bits of complexity.  For instance the interpreters are not independent, a breakpoint action that did:
> 
> target select TargetB
> some commands
> 
> will now have to swap command interpreters in mid-flight.  You'd also have to teach the interpreters to share a Python interpreter (since you want them to shared variables, etc for cool-o cross-target debugging experiments.
> 
> We'd also have to add a layer of heuristics on the "settings set" command, since they are currently held by the interpreter, but often you would be surprised if a setting didn't apply to some new target because it didn't share the same interpreter.
> 
> I also think it would be weird to have the help text dependent on the currently selected target.  That just seems like it would make things overly magical.  I would like a place to go to see all the options, so I have some hope of finding that vaguely remembered one-time-it-was-useful option without having to manually create all the platforms/targets I ever made to see which one had it.  I think it would be much better for the help to show all options and just indicate which ones were currently available.
> 
> Jim
> 
> 
> 
> 
> 
> 
>