[lldb-dev] LLDB API c++ exports

[Greg Clayton]

> On May 27, 2014, at 2:06 PM, Zachary Turner <zturner at google.com> wrote:
> 
> In trying to clean up the warnings in the Windows build, I found the
> most prominent warning to be C4251 ('identifier' : class 'type' needs
> to have dll-interface to be used by clients of class 'type2').  This
> is because almost all of the exported classes (e.g. SBAddress, etc)
> contain an stl object as part of their interface, usually a smart
> pointer.  This is a bad idea, as described in the following post:
> http://stackoverflow.com/questions/5661738/how-can-i-use-standard-library-stl-classes-in-my-dll-interface-or-abi
> 
> The warning can usually be ignored if none of the non-exported classes
> are made accessible through the public interface of the class, and it
> seems that at least some effort has been made to see that this is the
> case, but it does not appear to always be true.  I've gone through
> each of the exported classes, and found the following instances where
> non-exported classes are exposed through the public interface:
> 
>    SBDebugger(const lldb::DebuggerSP &debugger_sp);
>    SBFrame (const lldb::StackFrameSP &lldb_object_sp);
>    SBProcess (const lldb::ProcessSP &process_sp);
>    SBQueueItem (const lldb::QueueItemSP& queue_item_sp);
>    void SBQueueItem::SetQueueItem (const lldb::QueueItemSP& queue_item_sp);
>    SBTarget (const lldb::TargetSP& target_sp);
>    SBThread (const lldb::ThreadSP& lldb_object_sp);
>    SBValue (const lldb::ValueObjectSP &value_sp);
>    lldb::ValueObjectSP SBValue::GetSP () const;
>    SBWatchpoint (const lldb::WatchpointSP &wp_sp);
>    lldb::WatchpointSP SBWatchpoint::GetSP () const;
>    void SBWatchpoint::SetSP (const lldb::WatchpointSP &sp);
> 
> I guess there are a couple of approaches to fixing this:
> 
> 1) Add a comment to each function explaining that it should be used
> only internally, and suppress the warning.
> 
> 2) Make the opaque pointer a raw pointer that is manually allocated in
> the constructor and de-allocated in the destructor.
> 
> #2 seems like the "best" approach, but it's also more work.  Does
> anyone have strong feelings one way or the other?

You can't do #2 because all objects are tracked internally using shared pointers and sometimes the only thing keeping the backing object alive is the shared pointer itself. If you switch to normal pointers the objects could disappear and you could end up using the memory pointed to by the raw pointer as something that is no longer the type it used to be.

All of the above mentioned APIs above are not needed from a public API perspective, they are used by the other lldb::SB class implementation files to create objects and use the pointers inside lldb::SB objects. So nothing needs to be changed. If you want you can #ifdef them out using something that would be defined for the "lldb" shared library build so the LLDB.SB*.cpp classes can use them, but would not be defined for anyone linking against the library.

Maybe we can use 


#if defined(LLDB_PRIVATE)
#endif

Around each function mentioned above. Then we would need the Xcode project and the make files to always define "LLDB_PRIVATE" when building LLDB.framework (macosx), lldb.so (linux) or lldb.dll (windows).

This should fix the warnings. The STL shared pointer classes are thread safe (atomic) and I really don't want to use anything else, so please don't change how the objects are owned within any lldb::SB* classes.

Greg Clayton