Tests on embedded platforms

[real-or-random]

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 https://github.com/bitcoin-core/secp256k1/pull/799#issuecomment-680744896

[real-or-random]

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]

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.