Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests on embedded platforms #804

Open
real-or-random opened this issue Aug 26, 2020 · 2 comments
Open

Tests on embedded platforms #804

real-or-random opened this issue Aug 26, 2020 · 2 comments

Comments

@real-or-random
Copy link
Contributor

right now the tests are hard to make run on any low memory target.

Is this because of heap allocation? too much stack allocation? something else? if you could specify the requirements/how can I check it myself I can start working on it if it's feasible to fix without adding too much complexity

Originally posted by @elichai in #799 (comment)

@real-or-random
Copy link
Contributor Author

I think @gmaxwell can say more about the memory requirements but one very simple issue with the current tests that they don't run on bare-metal targets because they assume:

  • CLI parameters (argc, argv)
  • fopen and /dev/urandom if you don't pass the seed on the command line (this is even an issue on non-cygwin windows!)
  • printf

If you want to run tests on bare-metal targets, you anyway need to do some manual work but maybe we should at least make it as easy as possible. I once wanted to run the tests on Trezor but then was too lazy, and used a different ARM target with a compatible instruction set instead.

This related to #593.

@gmaxwell
Copy link
Contributor

Your typical modern embedded device doesn't have much ram but they have a fair amount of memory mapped flash, static const data ends up in flash.

Some devices only care about signing or only care about verification. The linker will eliminate unneeded code if you're only using one ... but the tests use both, this makes the tests a bunch larger. It should be easier to run a signing-relevant-stuff-only test.

The verify contexts use a huge amount of ram currently, and the tests allocate several at once. Your typical hardware wallet doesn't really care that much about verify performance (if it's linking verify at all!)-- see #614

At several places the tests put an a rather large amount of data on the stack: in some cases just single objects are big secp256k1_scalar sr[512] but also because there are test functions that use a lot which could be easily split into other functions. It would be nice if the library avoided using more than 4kb of stack (or could be configured that way at least) and if the tests didn't use more than 8kb of stack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants