support cargo test

[brenzi]

Is there any chance we can make cargo test work with our enclave code?

it would be great if we could use standard cargo test. Right now we can only do handmade testing which is a lot less convenient to track

right now we get a clash between std and sgx_tstd:

   Compiling substratee-worker-enclave v0.6.0 (/home/abrenzikofer/substraTEE-worker/enclave)
error: duplicate lang item in crate `std` (which `test` depends on): `f32_runtime`.
  |
  = note: the lang item is first defined in crate `sgx_tstd` (which `substratee_worker_enclave` depends on)

error: duplicate lang item in crate `std` (which `test` depends on): `f64_runtime`.
  |
  = note: the lang item is first defined in crate `sgx_tstd` (which `substratee_worker_enclave` depends on)

error: duplicate lang item in crate `std` (which `test` depends on): `panic_impl`.
  |
  = note: the lang item is first defined in crate `sgx_tstd` (which `substratee_worker_enclave` depends on)

error: duplicate lang item in crate `std` (which `test` depends on): `begin_panic`.
  |
  = note: the lang item is first defined in crate `sgx_tstd` (which `substratee_worker_enclave` depends on)

error: duplicate lang item in crate `std` (which `test` depends on): `oom`.
  |
  = note: the lang item is first defined in crate `sgx_tstd` (which `substratee_worker_enclave` depends on)

error: aborting due to 5 previous errors

error: could not compile `substratee-worker-enclave`.

[dingelish]

generally speaking, cargo test collects all #[test]s and creates a binary with a fixed driver and libtest. we don't have chance to change the compiler ad libtest. so the only chance to use cargo test is to test the untrusted app, not the enclave.

good news is that we can use inventory and a proc-macro to implement something very similar to #[test] which collect every test fn pointer (decorated by the customized proc macro attribute) into a static array and then drive these test fn ptrs with our own prebuilt driver. in this way, though we cannot use #[test], we can construct an only with all test fns automatically, and export only 1 ECALL fn for triggering the tests.

[dingelish]

though our initial PoC works, it has problem with ld from LLVM9, which optimizes out ctors.
related issues:
mmastrac/rust-ctor#27
mmastrac/rust-ctor#43

[brenzi]

this approach is acceptable. important for us is that tests are collected automatically and results are summarized clearly

[volcano0dr]

though our initial PoC works, it has problem with ld from LLVM9, which optimizes out ctors.
related issues:
mmastrac/rust-ctor#27
mmastrac/rust-ctor#43

Regarding the # [ctros] link issue, unused symbols are pruned, even if # [used] is used.
After testing, the following method can be used to temporarily solve this problem:
When linking test-enclave.a in your Makefile, use the whole-archice ld command line option
-Wl,-whole-archive -ltest-enclave -Wl,-no-whole-archive

[mssun]

@brenzi, please refer to this PR (apache/incubator-teaclave#269) on how to use inventory to automatically collect test cases.

[dingelish]

@mssun perhaps we could "downport" it to the sdk and make it available to developers like @brenzi

[mssun]

In addition to the automatic collection of test cases, we can also provide a cargo subcommand such as cargo teaclave. When executing cargo teaclave test, it can automatically provide an integration test driver.

The only thing bothers me about "downport" is that the update of SDK requires huge efforts. Test drivers, however, is not as stable as std. A better way is to implement this in the Teaclave platform first and stablize in the SDK when necessary.

In summary, @brenzi, you can simply implement your own test drivers first (similar with apache/incubator-teaclave#269). Then, we can gradually improve the test toolchain in the SDK.