Skip to content

[RFC] meson: Don't require RTTI to match between LLVM and Mesa

Jesse Natalie requested to merge jenatali/mesa:rtti-mismatch into main

Looking at the history of when the RTTI matching was added to Meson 3 years ago, I can't find any concrete evidence that something was broken beforehand. I'm struggling to understand why the RTTI choice of one component needs to affect another.

The reasoning I found is "building with/without rtti changes the ABI and my understanding is that there's no requirement for code with rtti to correctly link with code not using rtti." I'm not sure I see that though. The Itanium ABI uses the same VTable layout with and without RTTI: the field before the virtual functions is where the typeinfo pointer goes, but for VTables emitted in files that were compiled without RTTI, it's set to null. The Windows ABI is similar.

Essentially, the only consequence I can see would be if an object compiled with RTTI tried to use dynamic_cast, typeinfo, or tried to throw an exception whose type's VTable was defined in an object without RTTI. As an experiment I tried this with both Itanium and Windows ABIs:

  • Itanium produces a linker error for the typeinfo for <class> that wasn't provided by the objects compiled without RTTI. If I limit the RTTI usage to types that were compiled in objects with RTTI, everything's fine.
  • Windows actually links and works, because the vftables are emitted into all objects with "pick largest," and the definition with RTTI is larger than the one without.

So... I'd like to remove this early hard error unless there's specific badness that people can point me to that I'm ignorant of. Full disclosure: I dislike rebuilding LLVM.

Merge request reports