| Age | Commit message (Collapse) | Author |
|---|
|
...that ae6ee262d7649222a137f8722886a10db274ddf5 "Some fixing of
msvc_win32_arm64 UNO bridge" had removed, assuming it wasn't actually necessary.
But looks like Windows exception handling stack unwinding somehow needs it after
all. Getting past the CustomTarget_testtools/uno_test getRaiseAttr1() call now
(but still failing at some later place).
Change-Id: I1e84345f2f355ab1e480c779da6b221b744132b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166616
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
For one, the Windows ABI deviates from the generic aarch64 ABI regarding
returning class instances by value from non-static member functions, see
<https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#return-values>:
"The caller shall reserve a block of memory of sufficient size and alignment to
hold the result. The address of the memory block shall be passed as an
additional argument to the function in x0, or x1 if $this is passed in x0. The
callee may modify the result memory block at any point during the execution of
the subroutine. The callee returns the address of the memory block in x0."
That means RETURN_KIND_HFA_FLOAT and RETURN_KIND_HFA_DOUBLE are not needed, and
can be cleaned up in a follow-up commit.
And for another, setting up a call stack frame in call() in uno2cpp.cxx for
callVirtualFunction() didn't actually work, so go with a slightly less ambitious
aproach (as also used by the gcc_linux_aarch64 bridge) and explicitly copy the
arguments that end up on the stack around in callVirtualFunction().
This allows CustomTarget_testtools/uno_test to proceed at least as far as the
call of getRaiseAttr1(), which still leads to an uncaught
css::uno::RuntimeException.
Change-Id: I4a8ec09c270864ac4de246d7e8d1f923198236b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166585
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
the stack variable doesn't point to the beginning of the array with the
values, instead the code creates a large general purpose register array (gpr)
with the floating point register (fpr) and stack just being offsets in
that one.
bridge isn't fully working with that fix yet, still some wrong pointers
ending up in the interface reference
Change-Id: I6f1e5f84f84aff34663090c20fe70d65e0a7a334
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150578
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Since Microsoft follows the general ARM64 ABI calling conventions,
and the SEH exception handling is the same, this result is a mixed
port of the gcc3_linux_aarch64 bridge and the refactored x86-64
exception handling.
I have no idea, if the complicated 32-bit handling in RaiseInfo()
is needed, as the ARM64 trampolines definitly use 64-bit code.
But since this is the first working version, I currently don't
mind much ;-)
There is definitly more potential for refactoring in the whole
bridges directory...
Change-Id: I9782a2e99c0231cdd1286af156ad312229eccf39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103642
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|