[Mesa-dev] RFC: LLVM, -fno-rtti, and Haiku

[Kenneth Graunke]

On 10/11/2013 11:45 AM, Francisco Jerez wrote:
> Kenneth Graunke <kenneth at whitecape.org> writes:
> 
>> On 10/11/2013 09:50 AM, Francisco Jerez wrote:
>>> Kenneth Graunke <kenneth at whitecape.org> writes:
>>>
>>>> On 10/10/2013 04:27 PM, Alexander von Gluck IV wrote:
>>>>>
>>>>> In llvm.py -fno-rtti is always a build flag if LLVM present >= 3.2
>>>>>
>>>>> This breaks everything on our end (missing rtti related symbols) in our
>>>>> C++ libGL.so as Haiku uses dynamic casts.
>>>>>
>>>>> We build our LLVM packages with rtti (REQUIRES_RTTI=1).
>>>>>
>>>>> Not 100% sure why we're forcing no-rtti if LLVM >= 3.2.
>>>>> "llvm-config --cxxflags" should always show "-fno-rtti" if REQUIRES_RTTI=1
>>>>> wasn't set at build time. If REQUIRES_RTTI was set, -fno-rtti is removed
>>>>> from the llvm-config cxxflags.
>>>>>
>>>>> It was originally added here:
>>>>> http://cgit.freedesktop.org/mesa/mesa/commit/scons/llvm.py?id=d37ae642034bcaca39492c1eb75b029fb27ceffb
>>>>>
>>>>> My solutions are either removing the forced -fno-rtti, or wrapping it
>>>>> with a platform != 'Haiku'
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>  -- Alex
>>>>
>>>> I would love to see us build with -fno-rtti for all Linux builds.  I've
>>>> been meaning to try that and measure the impact.
>>>>
>>> The -fno-rtti option is evil, it changes the C++ ABI in an incompatible
>>> way.  As you may have noticed from the build error, in some cases it's
>>> impossible to link normal C++ object files with -fno-rtti object files
>>> if the interface between them exposes polymorphic types.
>>>
>>> That's the reason why some LLVM versions require us to build the
>>> interfacing module with -fno-rtti, and the same versions require us to
>>> build *without* -fno-rtti if RTTI was enabled in the LLVM build, as
>>> might be the case in Haiku and some Linux distributions.
>>>
>>> AFAICT the 'if' statement in scons/llvm.py:198 and the automake
>>> conditional in configure.ac:1953 are broken and should probably be
>>> removed.  LLVM doesn't require -fno-rtti unless llvm-config says
>>> otherwise, and if it still does in some case it's an llvm-config bug
>>> that can probably be addressed differently.
>>>
>>> I don't think it's a good idea to enable -fno-rtti except for isolated
>>> modules that can be guaranteed not to expose or use any C++ API.  There
>>> are legitimate uses of RTTI, and enabling -fno-rtti means that modules
>>> that use it cannot talk to modules that don't.
>>>
>>> Thanks.
>>
>> Which would be fine for Mesa (except maybe on Haiku), since all of our
>> usage of C++ is internal and we don't expose /any/ C++ API.  Nor should we.
>>
>> It looks like Clover uses RTTI.  Nothing else does, and I'd like to keep
>> it that way.
>>
> 
> Clover has a legitimate reason to do so -- and it's not the only user
> BTW, the nv50 compiler and 'src/gtest' seem to use it too.  Anyway, even
> if we don't use RTTI internally, building with -fno-rtti is a bad idea,
> because it makes interfacing with other C++ projects extremely
> difficult.

You mean LLVM?  My point is that Mesa does *not* interface with other
C++ projects.  It's an OpenGL library that exposes a 100% C API.  It
doesn't make *sense* to interface with other C++ projects.

> It can also cause problems in cases where we don't expose any C++ API
> ourselves and we are mere users of some C++ library -- like the Haiku
> system libraries or LLVM (IIRC even LLVM recommends distributions *not*
> to use -fno-rtti in their builds because of the ABI issues).  I don't
> see the point of making our internal C++ ABI deliberately non-standard,
> it's likely to give us more headaches for little or no benefit...

If it's necessary for LLVM, then I guess that trumps the overhead of
having to compile with RTTI.  But I know even LLVM reimplemented
dynamic_cast<> to avoid the cost of RTTI.

Other than LLVM, I don't think we will ever depend on any C++ library.

--Ken