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

[Pavel Labath via lldb-commits]

+ Shivam (Up until today I thought this was just theoretical musing but
now I realized that there is actually some work going towards this.)

On 25/06/2020 20:45, Jim Ingham wrote:
> 
> One of the things that is core functionality in the debugger is “when X
> happens, do Y”.  When I stop, do something, when I hit a breakpoint do
> something, when a new shared library is loaded (we don’t offer this
> affordance yet, but we should), etc…  Similarly the script interpreter
> side of lldb gets pretty involved in formatting data.  Both of these
> tasks require non-trivial managing.   I think it would be annoying for
> every debugger client to have to code that up themselves.  Some of that
> can be clearly expressed as generic debugger behavior (like running a
> condition on a breakpoint hit.)  But you also want a callout to more
> customizable behaviors.  At base, of course, these are just callbacks
> and don’t necessarily involve the script or command interpreters.

Yes, I was imagining these would be callbacks...

> But
> there’s a lot of bits of business particular to when the callbacks are
> running CLI or Script code, and it would be annoying to have every
> client have to reimplement these.
> 
> For instance, all CLI's will want to have to have a place to store the
> command callback text in the entities that are going to use them.  They
> would want that text to be part of the object’s “description” of itself.
>  And probably some other things that I’m forgetting.
And in that world, this information and the object "descriptions" would
probably not be parts of the objects themselves, but defined by the
particular CLI implementation (e.g., since the hypothetical gdb CLI
might want to format breakpoints differently than we normally do)...


> I think we could
> make these sockets sufficiently light-weight that having them in the
> core debugger wouldn’t have any practical downsides, and would make
> building on top of it easier.  That’s why I am inclined to include this
> part of the Command & Script interfaces in the CoreDebugger.
> 
> But I agree, the CoreDebugger should not include the implementation of a
> particular CommandInterpreter or a particular ScriptInterpreter, and
> should handle not having an actual CommandInterpreter present, as it can
> handle not having a ScriptInterpreter present.

... but I'm not really opposed to this design either (instead of a null
command interpreter, I might go for a no-op interpreter). I mainly want
to ensure that the roles and responsibilities of the different
components are well defined. The reason I'm going on about the gdb
emulator is not because I want to implement one (well.. maybe one day,
if I am extremely bored), but because it seems like a reasonable
criterion to decide which component does a piece of functionality go in.

> 
> I don’t see the layering problem, however.  In my view, there would be
> an abstract lldb_private::CommandInterpreter that receives text for
> execution returns results in a generic lldb_private::CommandResultObject
> (the current HandleCommand, HandleCommands).  It would provide an
> abstract “pretty print command text” call so that we could use it in the
> Description methods of lldb_private objects (for instance for
> breakpoints…)  It could also offer completion on types, filenames,
> variable names etc, since that’s a generic bit of functionality any CLI
> might want to use.  It might even have “HandleCompletion”, since that
> only knows that the command is text with a cursor…  But that’s about
> all.  This is clearly all within the lldb_private API’s.  We could
> probably also make “RunCommandInterpreter” sufficiently general that it
> might be worth adding that to the core functionality, and since this is
> a fairly complex bit of business because of I/O handlers and the like
> this seems worth trying.  But again, no SB API’s would be involved here.
>  Then there would be SP API’s that publish this functionality.  Again,
> this is just about storing and running the commands, so it doesn’t
> depend on any details of the interpreter.
> 
> Then for lldb, we would build a LLDBCommandInterpreter that uses the SB
> API’s to implement commands, and adds functionality like
> “DefineOptionGroup", “DefineCommand”, etc to set up commands in the
> command interpreter and would implement HandleCommand so that it could
> be run by the lldb_private::Debugger functionality.  But this would all
> be clearly on the outside of lldb_private.
> 

Right. I am not saying there necessarily _has_ to be a layering problem.
However, I do think that one has to design the thing carefully to ensure
he doesn't create one. I don't fully understand the design you're
proposing, but it does sound you've given it a lot of thought, and the
parts I do understand seem ok, and sound like they could be made to work.

However, the fact that D82723 starts by throwing everything into the
same bag does not sound reassuring to me. I'd like to understand how
those patches tie in with the design you mentioned. I also want to
preserve some sort of hierarchy in the code base.

pl