Yes, I don't think we can remove SBDebugger::Initialize/Terminate, but we could
document them:
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> help(lldb.SBDebugger.Initialize)
Help on function Initialize in module lldb:
Initialize()
Initialize()
We could even add lldb::Initialize & Terminate and say in the
SBDebugger::Initialize & Terminate that we'll get rid of them at some point, so
use the lldb:: ones instead.
Jim
> On Oct 8, 2014, at 10:16 PM, Matthew Gardiner <[email protected]> wrote:
>
> Thanks Greg,
>
> Yes, my confusion stemmed from the scoping of the functions.
>
> It would have been better, as you'd stated, if we'd have got:
>
> namespace lldb {
> void Initialize();
> void Terminate();
> }
>
> But I appreciate that the C++ API is hard to change. Sorry about
> previous confusion.
>
> There's a couple of additions I would like to make to the API soon,
> which will benefit the kalimba non-8-bit byte stuff. I'll build test
> cases first and add a review before doing anything drastic first.
>
> thanks
> Matt
>
>
> On Wed, 2014-10-08 at 11:26 -0700, Greg Clayton wrote:
>>> On Oct 7, 2014, at 10:15 PM, Matthew Gardiner <[email protected]> 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
>>
>>
>>
>>
>> To report this email as spam click
>> https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== .
>
>
>
>
> Member of the CSR plc group of companies. CSR plc registered in England and
> Wales, registered number 4187346, registered office Churchill House,
> Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Keep up to date with CSR on our
> technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people,
> YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> www.twitter.com/CSR_plc.
> New for 2014, you can now access the wide range of products powered by aptX
> at www.aptx.com.
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
