git: 9097e3cbcac4 - main - Partially revert libcxxrt changes to avoid _Unwind_Exception change

Tijl Coosemans tijl at FreeBSD.org
Sun Mar 14 20:00:55 UTC 2021


On Sun, 14 Mar 2021 01:15:11 +0100 Dimitry Andric <dim at FreeBSD.org>
wrote:
> On 13 Mar 2021, at 18:38, Tijl Coosemans <tijl at FreeBSD.org> wrote:
>> On Sat, 13 Mar 2021 13:54:49 GMT Dimitry Andric <dim at FreeBSD.org> wrote:  
>>> The branch main has been updated by dim:
>>> 
>>> URL: https://cgit.FreeBSD.org/src/commit/?id=9097e3cbcac455eb0dedd097d8d5548c72568d0a
>>> 
>>> commit 9097e3cbcac455eb0dedd097d8d5548c72568d0a
>>> Author:     Dimitry Andric <dim at FreeBSD.org>
>>> AuthorDate: 2021-03-13 13:54:24 +0000
>>> Commit:     Dimitry Andric <dim at FreeBSD.org>
>>> CommitDate: 2021-03-13 13:54:24 +0000
>>> 
>>>    Partially revert libcxxrt changes to avoid _Unwind_Exception change  
> ...
>>> --- a/contrib/libcxxrt/unwind-itanium.h
>>> +++ b/contrib/libcxxrt/unwind-itanium.h
>>> @@ -79,12 +79,9 @@ struct _Unwind_Exception
>>>   {
>>>     uint64_t exception_class;
>>>     _Unwind_Exception_Cleanup_Fn exception_cleanup;
>>> -    uintptr_t private_1;
>>> -    uintptr_t private_2;
>>> -#if __SIZEOF_POINTER__ == 4
>>> -    uint32_t reserved[3];
>>> -#endif
>>> -  } __attribute__((__aligned__));
>>> +    unsigned long private_1;
>>> +    unsigned long private_2;
>>> +  } ;  
>> 
>> Shouldn't these definitions be the same as the ones in GCC?  
> 
> If you want to keep the ABI compatible with what it was, no. Otherwise,
> you could consider it. But for what gain?

Hmm, the ABI must have been broken by the switch to libcxxrt years ago.
In that case there's ABI breakage no matter which version you choose.
Maybe kib can help decide which is the lesser evil.

In any case I do think the definitions in GCC should match the ones in
base.  Sometimes libraries compiled with GCC are combined with libraries
compiled with Clang in one process.  So, code compiled with GCC unwind.h
should work with base system libgcc_s and code compiled with libcxxrt
unwind.h should work with GCC libgcc_s.  Maybe the GCC ports can be
patched to match the base system but I'm not sure upstream would accept
such a patch, especially since upstream libcxxrt has already become
compatible.


More information about the dev-commits-src-main mailing list