Re: new bridgetest failures in 7.6 on ppc64le

[Dan Horák <dan@xxxxxxxx>]

On Thu, 31 Aug 2023 14:04:34 +0200
Stephan Bergmann <sbergman@xxxxxxxxxx> wrote:

> On 8/31/23 13:51, Dan Horák wrote:
> > On Thu, 31 Aug 2023 10:21:05 +0200
> > Dan Horák <dan@xxxxxxxx> wrote:
> > 
> >> Hello,
> >>
> >> I am working with the Fedora LibreOffice team on keeping LO building on
> >> ppc64le and s390x platforms and we found some new test failures during the
> >> rebase to 7.6. This is the first of them.
> >>
> >> ...
> >> [CXX] vcl/qa/cppunit/GraphicTest.cxx
> >> [CXX] vcl/qa/cppunit/GraphicDescriptorTest.cxx
> >> two floats struct test failed
> >> four floats struct test failed
> >> standard test failed
> >> exception occurred: error: test failed! at /home/sharkcz/projects/libreoffice/testtools/source/bridgetest/bridgetest.cxx:1268
> >>
> >>> error: error: test failed! at /home/sharkcz/projects/libreoffice/testtools/source/bridgetest/bridgetest.cxx:1268
> >>> dying...make[1]: *** [/home/sharkcz/projects/libreoffice/testtools/CustomTarget_uno_test.mk:26: /home/sharkcz/projects/libreoffice/workdir/CustomTarget/testtools/uno_test.done] Error 1
> >> make[1]: *** Waiting for unfinished jobs....
> >>
> >>
> >> I have tracked it down to
> >> https://git.libreoffice.org/core/+/32c845cb4389aba9430ce471b04f2891f5ff630d%5E%21/
> >> So I guess it possibly uncovered a real issue somewhere else.
> >>
> >> Seems the TwoFloat/FourFloat checks from
> >> https://git.libreoffice.org/core/+/refs/heads/master/testtools/source/bridgetest/bridgetest.cxx#472
> >> are called twice during "make unitcheck" and the second run returns
> >> garbage in the second (and third/fourth?) member. Any pointers where to
> >> look further or any help on resolving it would be appreciated.
> > 
> > and before the mentioned commit the check is run only once. Doesn't it
> > mean the Java bridge is broken for ppc64le, because it now runs the
> > Java test as well?
> 
> Smells a bit like it, though that would also be somewhat odd as that 
> bridge should mostly be platform-agnostic.
> 
> While the first test checks a roundtrip from C++ 
> (testtools/source/bridgetest/bridgetest.cxx) to the binary UNO hub to 
> C++ (testtools/source/bridgetest/cppobj.cxx) and back, that second test 
> checks a roundtrip form C++ (testtools/source/bridgetest/bridgetest.cxx) 
> to the binary UNO hub to Java 
> (testtools/com/sun/star/comp/bridge/TestComponent.java) and back.
> 
> Maybe bridges/source/jni_uno/jni_data.cxx Bridge::map_to_uno/_java are 
> good first pointers where to look for corrupted values in-flight, and 
> then go from there...

finally I can report some progress with this issue, although only with
understanding what is going on. Seems to be another ABI issue, the
resulting TwoFloat struct is returned back to performTest() [1] in a
general purpose register (r3) as it would be a single "int64" value. It
should be returned in floating point registers (f1, f2) as it is a
homogeneous struct with float members. If I see right in my debugging,
then it breaks in the last step when converting back from the UNO
format to the native C++. The previous Java to UNO step looks OK to me.
Is MapReturn() from the "cpp_uno" bridge [2] involved there? And I
believe the same applies to the FourFloat struct test.

I would appreciate any tips and tricks how to attack this problem with
gdb, because I wasn't successful in getting into the right place or
process and relied mainly on the old school "printf" method :-)

[1]
https://git.libreoffice.org/core/+/refs/heads/master/testtools/source/bridgetest/bridgetest.cxx#474
[2]
https://git.libreoffice.org/core/+/refs/heads/master/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx#95


	Thanks,

		Dan