[libcxx-dev] Contributions to libc++abi for different ABIs

[Leonard Chan via libcxx-dev]

Hi all,

We're attempting to implement a PC-relative vtable ABI for C++ in Fuchsia
<https://reviews.llvm.org/D72959> and I wanted to ask about the etiquette
for contributions to libc++abi for different ABIs.

The purpose of this ABI is to replace the 64 bit absolute address of
virtual functions in a vtable with 32 bit relative offsets between the
vtable and the virtual function. This would effectively make the vtable
readonly and help save on memory by reducing copy on write pages. The same
technique is applied to the typeinfo pointer in the vtable, replacing it
with an offset to the typeinfo object.

We ran into an issue though where changing the size and value of this
typeinfo component breaks dynamic_cast. More specifically, in this snippet
from __dynamic_cast in libc++abi:

```
    // Get (dynamic_ptr, dynamic_type) from static_ptr
    void **vtable = *static_cast<void ** const *>(static_ptr);
    ptrdiff_t offset_to_derived = reinterpret_cast<ptrdiff_t>(vtable[-2]);
    const void* dynamic_ptr = static_cast<const char*>(static_ptr) +
offset_to_derived;
    const __class_type_info* dynamic_type = static_cast<const
__class_type_info*>(vtable[-1]);
```

there is an assumption that the offset_to_derived is 16 bytes behind the
first function in the vtable, where for us it would take 12 bytes (8 for
the offset to top + 4 for the relative rtti component). The same thing
applies to __class_type_info which instead should be 4 bytes behind the
vtable pointer and would require an additional dereference and add since
it's an offset for us.

Off the top of my head, it seems like a simple solution to this is to
create another __dynamic_cast function (like
__dynamic_cast_fuchsia_relative or something) that would calculate these
variables correctly for our ABI.

So, finally to my question, is the proper etiquette for making ABI changes
this way to contribute them to libc++abi directly, or is there another
recommended way? Or is there a better way to address this problem that I
haven't thought of yet? So far, this seems to be the only RTTI breakage I
could find, but I'm still actively looking.

Thanks,
Leonard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200124/be812692/attachment.html>