Re: git: b2127b6f1ae2 - stable/13 - Install unwind.h into /usr/include

On 5 Mar 2022, at 03:36, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
> 
> On Fri, 4 Mar 2022 19:25:06 +0100
> Dimitry Andric <dim@FreeBSD.org> wrote:
>> On 3 Mar 2022, at 21:30, John Baldwin <jhb@freebsd.org> wrote:
>>> 
>>> On 3/3/22 10:08 AM, Dimitry Andric wrote:
...
>> For some reason, with the libunwind headers instead, it now gets shifted
>> by 8 bytes. I think we are having a case of kludges upon kludges upon
>> hacks, which is now falling apart... :-)
>> 
>> In any case, if I unconditionally enable the "#if defined
>> _LIBCPPABI_VERSION // detect libc++abi" block in except.cxx, it does
>> detect the exception header successfully, the gengal.bin command does
>> not crash anymore, and the whole libreoffice build succeeds. The
>> libreoffice binaries even run OK, though I only did light testing, like
>> opening a doc file and messing around with it a little bit.
>> 
>> But I'm not sure if it is the solution we want. Maybe we should again
>> put in some sort of compat hack, to make the libunwind/libcxxrt
>> combination work for this scenario? (I think libreoffice is one of the
>> few applications that calls __cxa_throw directly, with its own deleter
>> function...)
>> 
>> -Dimitry
>> 
> 
> Thanks for your hard work!
> Maybe, editors/libreoffice should adapt to the change if __UNWIND_H__
> is defined in /usr/include/unwind.h, but if some others (including
> not-yet-ported softwares) have the same problem, compat hack on base
> would be better preferred.
> 
> If there is a standard way to avoid this (use already-existing wrapper
> function?), it would be better fixing editors/libreoffice with some
> hints written into porter's handbook.

There's something very strange going on here, as evidenced by yet
another gdb session:

(gdb) frame 2
#2  0x000000082c2e92e7 in __cxa_free_exception (thrown_exception=0x87b5aff00) at /share/dim/src/freebsd/llvm-14-update/contrib/libcxxrt/exception.cc:627
627                             ex->exceptionDestructor(thrown_exception);
(gdb) print thrown_exception
$31 = (void *) 0x87b5aff00
(gdb) print static_cast<__cxa_exception*>(thrown_exception)-1
$32 = (__cxa_exception *) 0x87b5afe88

So according to the spec, casting the void pointer 'thrown_exception' to
a __cxa_exception pointer, then subtracting 1, should give you the
original __cxa_exception struct. In this case, it subtracts 8 bytes,
going from 0x87b5aff00 to 0x87b5afe88.

Now I do exactly the same in the libreoffice frame one below, where the
incoming void pointer 'pExc' is the previous 'thrown_exception' value:

(gdb) frame 1
#1  gcc3::deleteException (pExc=0x87b5aff00) at bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx:139
139         OUString unoName( toUNOname( header->exceptionType->name() ) );
(gdb) print pExc
$33 = (void *) 0x87b5aff00
(gdb) print static_cast<__cxa_exception*>(pExc)-1
$34 = (__cxa_exception *) 0x87b5afe80

So in *this* function, subtracting 1 from a __cxa_exception pointer
subtracts 16 bytes instead, going from 0x87b5aff00 to 0x87b5afe80!

I don't know what causes this, except maybe that libreoffice pulls in
some different definition of __cxa_exception. It looks like they have
their own header for this:

https://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx

but it's not clear to me whether they are enabling any of these custom
declarations...

-Dimitry