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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development