This contains the updated patch for enabling Peter Collingbourne's relative vtable ABI (described in https://bugs.llvm.org/show_bug.cgi?id=26723) on Fuchsia. The goal is to reduce memory usage by making vtables readonly.
Key differences:
- LTO is not required
- No white listing of classes. Fuchsia does not guarantee C++ ABI stability, so anything running on Fuchsia should either by compiled with this ABI or not depend on the C++ ABI at all.
- Instead of taking the offset between the vtable and virtual function directly, we emit a DSO-local stub that just contains a tail call to the original virtual function, and take the offset between that and the vtable. We do this because there are some cases where the original function that would've been inserted into the vtable is not local or hidden and may require some kind of dynamic relocation which prevents the vtable from being readonly. On x86_64, taking the offset between the function and the vtable gets lowered to the offset between the PLT entry for the function and the vtable which gives us a PLT32 reloc. On Aarch64, right now only CALL26 and JUMP26 instructions generate PLT relocations, so we manifest them with stubs that are just jumps to the original function.
- Apply the same technique with the RTTI component in the vtable and emit a proxy that results in a GOTPCREL reloc.
- Update libcxxabi to use different arithmetic for finding the typeinfo pointer given the vtable pointer for Fuchsia
- Hide the ABI behind a flag -fexperimental-relative-c++-abi-vtables that is only available through CCI (-Xclang will need to be passed before it)
I think we should omit the Fuchsia bit and make it a generic, this feature should be usable by any target.