[lldb-dev] Object identities in the LLDB's C++ API

[Greg Clayton via lldb-dev]

> On Dec 13, 2017, at 11:44 AM, Leonard Mosescu via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> LLDB's C++ API deals with SBxxx objects, most of which are PIMPL-style wrappers around an opaque pointer to the internal implementation. These SBxxx objects act as handles and are passed/returned by value, which is generally convenient, except for the situations where one would need to keep track of object identities, ex. using them as keys in associative containers.
> 
> As far as I can tell, there's a bit of inconsistency in the current state:
> 
> 1. Some types, ex. SBThread, SBTarget, SBSection, ... offer ==, != that map directly to the corresponding operator on the opaque pointer (good!), but:
>     .. there are no ordering operators, nor obvious ways to hash the objects
> 2. SBModule offer the == , != operators, but:
>     ... the implementations for == and != are not exactly forwarded to the corresponding operator on the opaque pointer (1)
> 3. Things like SBFrame offer IsEqual() in addition to ==, !=, creating a bit of confusion
> 4. Other types (ex. SBProcess, SBSymbol, SBBlock) don't offer any kind of comparison operations.
> 
> IMO it would be nice to have a consistent "handle type" semantics regarding identity, ordering and hashing. I can see the following options:
> 
> 1. Expose the opaque ptr as an opaque handle() 
>      - this is an easy, quick and convenient solution for many SBxxx types but it may not work for all

That would be nice, but that won't always work with how LLDB is currently coded for SBFrame and possibly SBThread. These objects will be problems as they can come and go and the underlying object isn't always the same even through they lock onto the same logical object. SBThread and SBFrame have "lldb::ExecutionContextRefSP m_opaque_sp" members. The execution context reference is a class that contains weak pointers to the lldb_private::Thread and lldb_private::StackFrame objects, but it also contains the thread ID and frame ID so it can reconstitute the value lldb_private::Thread and lldb_private::StackFrame even if the weak pointer isn't valid. So the opaque handle will work for many objects but not all.

> 2. Design and implement a consistent, first class identity/ordering/hashing for all the SBxxx types
>      - perhaps the most elegant and flexible approach, but also the most work

I would be fine with adding new members to classes we know we want to hash and order, like by adding:

uint32_t SB*::GetHash();
bool SB*::operator==(const SB*& ohs);
bool SB*::operator<(const SB*& ohs);

Would those be enough?


> 
> Any thoughts on this? Did I miss anything fundamental here?

> 
> Thanks,
> Lemo.
> 
> (1) example of operator== from SBModule:
> 
> bool SBModule::operator==(const SBModule &rhs) const {
>   if (m_opaque_sp)
>     return m_opaque_sp.get() == rhs.m_opaque_sp.get();
>   return false;
> }

So I would leave this up to the SB classes so that we can change the implementation if needed so I would prefer to add methods to each SB object for hashing and comparison.

Greg Clayton


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20171213/c94bc962/attachment.html>