[Development] How to run QtBase autotests on a remote machine?
arichardson.kde at gmail.com
Wed Apr 11 10:13:09 CEST 2018
I am currently trying to get Qt to work on the CHERI CPU
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 . Compared to other programs and
libraries that I have modified to run on CHERI QtCore has been quite
straightforward . 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
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
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 .
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
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
 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.
 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
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.
 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.
More information about the Development