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

[Leonard Chan via libcxx-dev]

I can see that as a viable option. My main concern is if this is the
"standard" way of doing things. A quick glance at libcxxabi/CMakeLists.txt
doesn't seem to show any previous examples of people doing this, but I
guess this could be the first time this happens.

On Fri, Jan 24, 2020 at 12:02 PM Petr Hosek <phosek at chromium.org> wrote:

> On Fri, Jan 24, 2020 at 11:42 AM Leonard Chan <leonardchan at google.com>
> wrote:
>
>> 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.
>>
>
> Could this be a build configuration (e.g. CMake option that changes the
> behavior or __dynamic_cast) that we would set when compiling libc++abi for
> Fuchsia? I don't think we want to change the existing code to use a
> different function when compiling for Fuchsia, rather we want the new ABI
> to be the default on Fuchsia and be completely transparent to the code and
> developers.
>
>
>> 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/6347b60f/attachment.html>