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

[Francisco Jerez]

Kenneth Graunke <kenneth at whitecape.org> writes:

> 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.
>
On a side note, it's always seemed quite funny to me that they did.  The
cost of run time type identification using typeid() is negligible on
modern C++ compilers (including Clang), as it can be optimized out to a
pointer comparison, and the cost of a dynamic_cast<> is comparable to
the cost of a virtual function call in most cases.

I'm aware that this hasn't always been the case historically, but it's
funny that they designed based on that as they were writing a compiler
and they could've just fixed what was mostly an implementation
issue... :)

> Other than LLVM, I don't think we will ever depend on any C++ library.
>
> --Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131011/29d9677c/attachment.pgp>