[lldb-dev] std::shared_ptr, RTTI, and LLDB

[Eli Friedman]

On Wed, Jun 9, 2010 at 3:54 PM, Greg Clayton <gclayton at apple.com> wrote:
>
> On Jun 9, 2010, at 3:44 PM, Eli Friedman wrote:
>
>> Currently, LLDB uses std::shared_ptr.  With gcc (or at least gcc 4.4),
>> that means RTTI must be enabled.  However, LLVM and clang build with
>> RTTI disabled (at least by default), so an RTTI-enabled LLDB won't
>> link.  So I have two questions:
>>
>> 1. How difficult would it be to stop using shared_ptr?
>
> We use a lot of shared pointers, though we aren't currently using the fancy RTTI aspects of it. We really want _some_ sort of shared pointer so we can have STL collections of objects that don't move around when collections grow. Also with a lot of our partial parsing we can determine how many objects there are in a collection, resize the collection to contain that many objects, then lazily populate such objects.

Okay... so it might potentially be possible to switch to something
simpler, more like boost::intrusive_ptr?  I won't bother if there's a
simpler solution, though; see below.

>> 2. Does the LLVM build in llvm.zip have RTTI enabled?
>
> No.
>
>> If so, how do you build LLVM that way?
>
> We don't. There are a few Clang/LLVM files that have RTTI manually disabled (add "-fno-rtti" to the compiler flags for these files) on them:
>
> ClangASTContext.cpp
> RecordingMemoryManager.cpp
> ClangASTSource.cpp

Ah, I see.  There's a bit of an issue here, then: LLVM's make system
only supports enabling/disabling RTTI on a per-directory basis.  Would
you mind moving those files into subdirectories?

> We try to not just intersperse Clang/LLVM just anywhere, we tend to try and abstract those calls behind one of these files. The main reason for this is then we know the interface that we will eventually require from LLVM/Clang when/if they ever vend shared library versions of themselves.

Oh... I don't know if you've noticed, but I've been doing things like
using llvm/ADT/StringExtras.h; is that not okay?

-Eli