[Development] How to run QtBase autotests on a remote machine?

[Alexander Richardson]

Hello,

I am currently trying to get Qt to work on the CHERI CPU
(http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html)
running a modified version of FreeBSD.
CHERI is a capability architecture with 128-bit pointers (memory
capabilities) and unlike on most other CPU architectures pointers are
*not* the same as a integers [1]. Compared to other programs and
libraries that I have modified to run on CHERI QtCore has been quite
straightforward [2]. I was pleasantly surprised by how easy it was to
get the configure
checks to pass and add the required custom command line flags to the
build systems.

I have now managed to get the first few unit tests to build and run as
CHERI pure capability programs so I would like to run the full test
suite.
Currently I build the tests and then scp individual tst_foo binaries
to the host and run them manually. In order to fix the initial porting
problems that will show up in most tests this is fine.
However, now I would like to run the full test suite to find any other
issues in Qt and/or our compiler/OS libraries/kernel.

I cannot run the compiler on the target platform due to memory and CPU
speed constraints so I need to cross-compile everything [3].
Is there any existing mechanism to run the unit tests on a machine
other than the compilation host?

I have noticed that there is a target_wrapper.sh script in every test
directory. Can that be modified to execute scp and ssh to run the test
remotely?
Currently, I am only attempting to run statically linked tests, but
once I have managed that I would also like to run them dynamically
linked which will probably require copying more files and setting
QT_PLUGIN_PATH.

Thanks,
Alex



[1] In CHERI we use capabilities instead of pointers. Our capabilities
hold a virtual address as well as metadata describing the memory
resources referenced by the pointer (bounds, permissions, ...) and
also a 1-bit tag that protects the pointer itself (integrity, valid
provenance, ...). This tag bit is cleared when a capability is
overwritten with plain data so there is no way integers and pointers
can be confused.

[2] The only real incompatibility I have found so far is that
QArrayData::data() stores an offset to the data instead of a pointer.
On CHERI pointers can only be created by subsetting an existing
capability.
For the common case where the string data is part of the same
allocation as the QArrayData header using  `return (char*)this +
offset` also works since it is just setting an offset in the allocated
memory region. However, the fromRawData() case does not work since
that requires creating a pointer that is out of bounds of the
QArrayData allocation and will cause a trap when accessed.
Other than this the majority of the work so far was changes to our
compiler+linker and the OS libraries. We have so far focussed mostly
on software written in C (and the libc++ testsuite) so compiling Qt
has exposed quite a few compiler crashes since it is the first big C++
project we have attempted to port.

[3] We can currently run CHERI code on QEMU
(https://github.com/CTSRD-CHERI/qemu) or on an FPGA running at about
100MHz. I could theoretically attempt to run a MIPS version of clang
in QEMU but it is so slow that using that approach is not feasible.