[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

The current status of LibreOffice testing cases on riscv64



Greetings!

The following talking are all based on source code compilation.

## Bridge

Bridgetest is partly failed. Cpp to cpp is OK, but the remote call from cpp to java is cracked. The reason is that uno2cpp cannot properly fill some struct data returned from the callee cpp function to uno environment. This causes the wrong order of parameters in the returned struct consist of one float and one int. The failing in Java bridge may causes the following failing test cases:

- [JUT] forms_unoapi_1
- [JUT] forms_unoapi_2
- [JUT] forms_unoapi_3
- [JUT] forms_unoapi_4
- [CUT] smoketest

The python side of pyuno does not work properly. Some simple types(such as bool and uint64) are returned with uncleaned higher bits. This may causes the following failing test cases:

- [CUT] sw_uiwriter5
- [UIT] cui_dialogs
- [UIT] writer_tests
- [UIT] writer_tests4
- [UIT] writer_tests7

In conclusion, the UNO bridge need to be refactored. I am working on it and there is still much to do.


## NaN Payload

I do not know how this feature affects the performance of libreoffice, since the error code is shown correctly on riscv64. The relative failing test cases are:

- [CUT] sc_ucalc_formula2
- [CUT] sal_rtl

These test cases may not be fixed in the short term due to lacking of NaN payload support on most riscv64 machines.

## GDB Debugging issue

One functionality of GDB cannot work ―― 'Print'. GDB cannot recognize any symbol of the program. When print a variable, GDB logs 'No symbol'. This seriously hinders the debugging work. I guess the reason is some wrong compilation parameters or fault compilation directives in call.s.

This bug should be fixed after the UNO bridge fixed.

## Other failing test cases

- [CUT] vcl_gtk3_a11y
etc.

From,
Sakura286.


Reply to: