-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
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:
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. |
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. |
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)
The text was updated successfully, but these errors were encountered: