--- Day changed Sun Feb 26 2017
00:35 < TD-Linux> wumpus, if you post your code I can play with it (I also have a sifive board)
00:37 < TD-Linux> keep in mind https://github.com/sifive/freedom-e-sdk/issues/42
02:31 -!- vFSgrcFGBJHg [~rYUtdcvYT@2a02:2f0a:b050:eea:934a:6abb:750c:602c] has quit [Quit: Leaving]     
05:12 < wumpus> TD-Linux: sure: https://github.com/laanwj/freedom-e-sdk/tree/secp256k1
05:15 < wumpus> gmaxwell: yes that would be useful on this platform, it has (IIRC) 16 MiB flash and only 16 kiB memory
05:19 < wumpus> I'm never going to use all 16MiB for code so I could just, say, dedicate the top 1.4MB to that table
05:53 < wumpus> oh I found the root cause: out of memory, malloc returns 0 in that test
05:54 < wumpus> and like on other small CPUs, writing to address 0 is actually a valid operation :)
07:20 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]     
07:20 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1     
09:13 < gmaxwell> wumpus: interesting, but we have code that detects malloc zero and attempts to commit suicide. I guess abort() on your device doesn't?
09:16 < gmaxwell> Another example of where we need context canaries.  (I think we should make the context object contain a value that is set when initilization is successful, set to something else when the context is freed.
12:34 < midnightmagic> TD-Linux: I also got my hifive thingy in the mail. It's very small. Any suggestions or things you've learned which might spare me hours of annoyance..?
14:37 < TD-Linux> midnightmagic, not really, it was really straightforward
14:38 < TD-Linux> they also have an arduino sdk, I haven't compared to see how their newlib and linker scripts compare
16:58 < midnightmagic> TD-Linux: thanks
22:12 < wumpus> midnightmagic: it seems really easy to get started with, as these things go
22:14 < wumpus> when compilng the sdk on aarch64 you need to replace two autoconf files (https://github.com/sifive/freedom-e-sdk/issues/51) or it will fail in openocd
22:15 < wumpus> gmaxwell: it helps if that function is also used everywhere, see https://github.com/bitcoin-core/secp256k1/pull/444
22:19 < gmaxwell> oh the tests!
22:19 < gmaxwell> wumpus: damn, good catch!
22:28 < wumpus> I still have the run_ge test commented out, and one edge case in ecdsa edge cases which uses a >16000 byte stack frame, the other tests pass
22:31 < gmaxwell> Which case has the 16000 byte stack frame?
22:32 < wumpus> "Nonce function corner cases."
22:32 < wumpus> I think due to secp256k1_scalar sr[512]
22:36 < gmaxwell> that would be it.
22:51 < wumpus> that'd be too much to allocate anywhere, not just on the stack, so that test simply cannot run on the hardware
22:52 < gmaxwell> yea-- thus my short reply, I don't see an easy way to effectively do that test without a lot of ram. It would be better to put it on the heap but wouldn't help you.
22:58 < wumpus> I mean on any modern-ish architecture, except for kernel mode, a 16k stack frame for a non-recursive function is not a big deal
22:59 < wumpus> all we could do is add an embedded mode to the tests that will skip memory-hungry tests like these, of which there are surprisingly few
22:59 < gmaxwell> wumpus: well I mostly tried to keep usage down.
23:00 < wumpus> that shows