[lldb-dev] [PATCH] For SBDebugger::Create assertion failure

[Greg Clayton]

> On Oct 7, 2014, at 10:15 PM, Matthew Gardiner <mg11 at csr.com> wrote:
> 
> On Tue, 2014-10-07 at 17:10 -0700, Greg Clayton wrote:
>> It is quite common for shared libraries to have initialize and terminate calls. We have this in LLDB. 
> 
> Agreed. Lots of libraries have to initialise resource, then release the
> resource upon terminate.
> 
> But why have an Initialise method when you _already_ have a Create
> method? Likewise a Terminate method when you _already_ have a Destroy
> method.
> 
> Surely when a "thing" is created that is also when it is initialised?

You are assuming there is no global context within the debugger like all registered plug-ins, lists, settings, global module list... These all work without requiring a debugger object. We could switch things so that all state is contained in the lldb_private::Debugger object, but then all places making static function calls would now need to have a debugger object. So think of SBDebugger::Initialize() more of a LLDB::Initialize() and SBDebugger::Terminate() as LLDB::Terminate(). We placed it into the SBDebugger class just for convenience since this is the most senior object in the hierarchy, but I can see how this is confusing.


> 
>> 
>> I would rather not have to look through all API calls that might require LLDB to be initialized and have to possibly manually call SBDebugger::Initialize() in there. The initialization does quite a bit and the assertion quickly should tell you that you must call SBDebugger::Initialize() first. If it isn't clear from the assertion, we can change the assertion to be more descriptive. But again, many other classes in the lldb::SB* API have functions that might be able to be used without having to start with a debugger, so I would rather not have to go through all of the API and add the "init the debugger if not already initialized".
>> 
>> This also allows you to use LLDB as a shared library and do:
>> 
>> SBDebugger::Initialize()
>> // Do something that takes up a bunch of memory
>> SBDebugger::Terminate()
>> 
> 
> Agreed. But surely in between the invocations of Initialise and
> Terminate, you have in some sense "created" an instance of an
> SBDebugger?

No that isn't required. There are other API calls you might be able to use (not many). Repeating what I stated above: SBDebugger::Initialize()/Terminate() are more really like LLDB::Initialize() and LLDB::Terminate(), so these calls are really things that populate all shared library globals.
> 
> 
>> So I vote to leave things as is.
>> 
> 
> To avoid rocking the boat, I reluctantly concede.

Since we already have this in the SBDebugger public API I would rather not change it, but it would be probably clearer if we had:

namespace lldb {
    void Initialize();  // Must be called prior to calling any other lldb::SB API calls
    void Terminate();	// No lldb::SB API calls should be called after calling this and before calling lldb::Initialize() again
}

Does that help explain what SBDebugger::Initialize() and SBDebugger::Terminate() actually are despite the wrong class scoping?

Greg