[lldb-dev] LLDB API c++ exports

jingham at apple.com jingham at apple.com
Tue May 27 14:39:17 PDT 2014

You can't use or make lldb::TargetSP's with the header files that exist on the SB side of the LLDB interfaces.  They are all shared pointers to opaque classes that are only defined in private headers.  Nor do any of the SB API's return lldb::*SP's, so you couldn't get one that way to pass to a call that takes one.  It is pretty clear that these are not meant for public consumption.

The SetSP/GetSP API's are all private or protected, and the SB classes are NOT meant to be derived from by the outside world, so these are explicitly not for public consumption.

As for the others, if you want to put a comment, feel free, though it would be kind of annoying to have this boilerplate comment repeated everywhere.  Might be better to put some policy rules in a common place (maybe LLDB.h or SBDefines.h) that says how the SB API's are to be used.


> 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?
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

More information about the lldb-dev mailing list