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

[Matthew Gardiner]

Well, yes, a clean API design would (eventually) move the
Initialise/Terminate functions out of the scope the SBDebugger entity.

Matt

On Thu, 2014-10-09 at 09:07 -0700, jingham at apple.com wrote:
> 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 <mg11 at csr.com> 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 <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
> >> 
> >> 
> >> 
> >> 
> >> 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
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>