tree: a6707ec5c6be1633804987ff935556e1d1834df6 [path history] [tgz]
  4. bad-segsel/
  5. bad-syscall/
  6. bti/
  7. c11-condvar/
  8. c11-mutex/
  9. c11-thread/
  10. channel-call-etc/
  11. channel-iovec/
  12. channel-write-etc/
  13. channel/
  14. clock/
  15. debuglog/
  16. default-exception-handler/
  17. elf-tls/
  18. event-pair/
  19. fifo/
  20. fpu/
  21. futex/
  22. handle-close/
  23. handle-dup/
  24. handle-info/
  25. handle-transfer/
  26. handle-wait/
  27. interrupt/
  28. job/
  29. kernel-unittests/
  30. libc-and-io-stubs.c
  31. memory-mapping/
  32. next-vdso/
  33. object-child/
  34. object-info/
  35. object-wait/
  36. page-size/
  37. pager/
  38. port/
  39. process/
  40. profile/
  41. pthread-barrier/
  42. pthread-tls/
  43. pthread/
  44. resource/
  45. socket/
  46. stack/
  47. stream/
  48. sync-completion/
  49. sync-condition/
  50. sync-mutex/
  51. syscall-generation/
  52. system-cpu/
  53. system-event/
  54. test-main-with-filter.c
  55. threads/
  56. time/
  57. version/
  58. vmar/
  59. vmo/


The “core” tests exist for one main purpose: To test basic functionality when things like devmgr aren't working.

There are two different ways in which core tests are built and run: unified and standalone.

Unified mode

In this mode, all core tests are built into a single executable that is directly invoked by the kernel. That is, the kernel is told to run core-tests instead of devmgr. In this mode the tests will run without any userspace device manager, device drivers, io plumbing, etc.

Example usage

fx set core.x64   # any of {bringup,core}.{x64,arm64} are fine too.
fx build
fx core-tests [--gtest_filter=FILTER] [--gtest_repeat=REPEAT]

The helper fx command runs QEMU (or FEMU) providing the specially-built core-tests.zbi as a -z argument.

Only a subset of tests can be specified by gtest_filter, e.g. --gtest_filter="FutexTest.*"

Tests can be rerun with gtest_repeat, e.g. --gtest_repeat=100 to run all tests 100 times or --gtest_repeat=-1 to run all tests until a test fails.

Standalone mode

In this mode, each test is built into its own binary which can be run “manually” from a serial shell or via runtests. Not all core tests can operate in standalone mode. For example, some tests require the root resource which is only available to tests running in unified mode. See unified_only in for a list of such tests.

Example usage

fx set bringup.x64 --with-base //bundles/bringup:tests
fx build
fx qemu

Then at the shell prompt,

/boot/test/core-futex --gtest_filter='FutexTest.Wakeup' --gtest_repeat=10


runtests /boot/test/core-*


The tests here are for “core” functionality (channels, etc.), but not all “core” functionality can go here. For example, you can‘t start a process in your test with launchpad because core tests are for when that functionality isn’t working. Core tests can't use fdio and launchpad uses fdio.

Since these tests can't use fdio core/libc-and-io-stubs.c stubs out the needed functions from fdio.