[Lldb-commits] [PATCH] D82155: [WIP][lldb/interpreter] Add ability to save lldb session to a file

[Pavel Labath via lldb-commits]

On 24/06/2020 18:55, Jim Ingham wrote:
> 
>> On Jun 22, 2020, at 5:52 AM, Pavel Labath via Phabricator via lldb-commits <lldb-commits at lists.llvm.org> wrote:
>>
>> labath added a comment.
>>
>> This seems like it could be useful in some circumstances, though for the use cases I am imagining (bug reporting) it would be easier to just copy-paste the terminal contents.
>>
>> As for the implementation, if the intention is for this to eventually capture all debugger output, then I am not sure if this is the right design. I think it would be fine for python/lua interpreters as those are invoked from the lldb command interpreter, but I have a feeling that routing the output printed via `Debugger::PrintAsync` back to the command interpreter would look pretty weird. It may make sense for the core logic of this to live in the Debugger or the IOHandler(Stack) classes -- though I am not exactly sure about that either as the Debugger and CommandIntepreter classes are fairly tightly coupled. However, I think that would be consistent with the long term goal of reimplementing the command interpreter on top of the SB API (in which case the `Debugger` object should not know anything about the command interpreter (but it would still need to to "something" with the PrintAsync output).
> This isn’t directly related to how much and how we should capture lldb session output, and maybe I’m misunderstanding your meaning, but I wasn’t expecting that moving the command interpreter to use SB API’s would mean the Debugger Object would know nothing about the Command interpreter.  It would know as much about the command interpreter as it does about the script interpreter, namely the Debugger holds these objects and is the one to hand them out.  For instance when the breakpoint has a bunch of commands in its command action, it would go to the debugger to evaluate those commands.  I think that’s the reasonable place from which to vend the command and script interpreters.  So it’s okay IMO for the Debugger to know a little bit about these entities.  It shouldn’t know anything about the command syntax, etc.  But since it is still the vendor of these objects, it seems okay for it to have an affordance to be notified of command results.
> 

Well, the way I was thinking about this the "Debugger" would not know
anything about Command *or* script interpreters. It would just know how
to "debug" -- offer a programming API without any sort of textual
interaction with a human.

However, this may be just a naming issue. There obviously needs to be
some object which ties all of these together the thing which "debugs"
and the thing which interfaces this with the user -- and it's not
unreasonable to call this thing "the Debugger".

Nevertheless I think having this separation between "core debugger
functionality" and a "particular way of interacting with the user" can
be very useful:
- it can enable someone to write a fully gdb-compatible (or some other
debugger emulation) CLI experience on top of the "debugger core". This
CLI would not need anything from the lldb CLI, but it could make use of
all the "core" functionality (targets, breakpoints, threads, etc.)
- someone wanting to build a lean-and-mean debugger for some specialized
task could just make use of the "core" debugger functionality without
pulling in the entire CLI

I don't expect either of these things to happen in the near future (or
at all), but I like that this design would enable that sort of thing.
Additionally (and this is the reason why I said (lldb_private::)Debugger
in my first comment) this organization would avoid some problematic
circular dependencies: If lldb_private::Debugger knows about the
"command interpreter" and the "command interpreter" uses the SB api,
then which side of the SB boundary does the command interpreter lie? It
can't be "inside" the API, because it needs to access it to drive the
debugging. But it also cannot be "outside" of the SB API, because then
lldb_private::Debugger could not know about it.

That's why I figured that lldb::SBDebugger could be the "one debugger to
rule them all", and lldb_private::Debugger could be "demoted" to just
the "core" debugging facilities.

But now we're getting way ahead of ourselves...

pl