Fix imports in ctap, embedded_flash and lang-items.

[gendx]

This pull request fixes the way modules are imported depending on features in src/ctap and src/embedded_flash. It also adds a stub in lang-items with the std feature to prevent any linker error.

This prepares #149.

• Tests pass
• Appropriate changes to README are included in PR

[ia0]

I guess that's also a solution: have all modules be in both the library and the binary with the same paths. That's not clean but it's probably cleaner to read than controlling the module memberships with a feature. The main danger is that we should make sure the library is not used by the binary to avoid code duplication (and bigger binary size).

Was this tested on a board?

[gendx]

I guess that's also a solution: have all modules be in both the library and the binary with the same paths. That's not clean but it's probably cleaner to read than controlling the module memberships with a feature. The main danger is that we should make sure the library is not used by the binary to avoid code duplication (and bigger binary size).

The reproduced binaries have a larger .text section, but it's still reasonable. We can anyway later split out everything in libraries and keep the binary as thin as possible.
And wouldn't potential duplicated code be stripped with LTO?

Was this tested on a board?

Not yet.

[gendx]

Was this tested on a board?

I tried:

$ ./deploy.py --board nrf52840dk --panic_test
$ ./deploy.py --board nrf52840dk --panic-console --panic_test
$ ./deploy.py --board nrf52840dk --panic-console --debug --panic_test
$ ./deploy.py --board nrf52840dk --panic-console --debug --debug-allocations --panic_test
$ ./deploy.py --board nrf52840dk --oom_test
$ ./deploy.py --board nrf52840dk --panic-console --debug --debug-allocations --oom_test
$ ./deploy.py --board nrf52840dk --panic-console --debug --debug-allocations --opensk

I tried OpenSK itself on both https://webauthn.io/ and https://webauthn.me/.

All as expected.

[ia0]

The reproduced binaries have a larger .text section, but it's still reasonable. We can anyway later split out everything in libraries and keep the binary as thin as possible.

It's not that "we can", we should avoid this error-prone code duplication, besides the fact that this is bad design. This is just a temporary workaround to enable fuzzing. We should create an issue to track this tech debt.

And wouldn't potential duplicated code be stripped with LTO?

Not necessarily. If the same function is used from its library path and its binary path, then I'm not sure the linker is allowed to merge the symbols even if they have the same code, because they have different names and would thus get the same address.