[lldb-dev] Native windows debugging support

[Zachary Turner]

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?




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
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140702/1b00bc43/attachment.html>