Verify Math Floating Point consistency

[mhofman]

In endojs/endo#1319 we note that Math's floating point operations may provide slightly different results depending on the engine / OS / architecture. While we may be immune from the first given we're currently relying on the XS engine, the second and third point may differ between validators. Also the XS engine will need updates and while we have a story about managing updates with potential execution differences, we should actually ensure no Math based divergences sneaks into patch updates.

One item may be to add a test similar to fingerprinting with the expected values hardcoded to detect any such divergences.

[warner]

We might add a unit test to agoric-sdk that enforces what we think is the majority behavior, and declare that validators must run on a platform that passes the unit test suite. Or we might add a quick check at runtime which crashes early if the non-majority behavior is detected.

Of course, if the difference is visible between an amd64 linux host and an aarch64 M1 Mac laptop, then I'm gonna ask for a better mitigation scheme, because I like being able to run our tests on my own machine :)

[mhofman]

From memory, I believe we looked into this and that XS relies on the OS stdlib and the CPU for some of these operations, which means the result could diverge between platforms. While we only officially support Linux on x64 for operating validators, even in that mode there could be divergences. We should get xsnap to adopt a library like fdlibm to prevent this potential source of divergence.

[mhofman]

I have verified that some results of the fingerprint test above differ between an x64 machine and an arm64 machine.

[mhofman]

Moddable has an experiment using fdlibm for more Math operations, solely through headers defines in the host app (xsnap-worker in our case)