-
-
Notifications
You must be signed in to change notification settings - Fork 1k
Description
We currently build with function pointer cast emulation. It is really hard to remove this because it is hard to know where bad function calls are being made (i.e. where an indirect call is made where the call arguments don't match the target function arguments).
I would suggest that what is needed is some kind of fpcast_emulation with tracing build, then run the full test suite on that, hopefully it would hit the majority of the function pointer casting shenanigans. In theory this was fixed in python in 3.8, so we should be good with core python, but we do bundle some other stuff for images and fonts etc. that might cause issues. The patches to scipy/numpy removed most issues there too, but there may be some that I missed.
I suspect the easiest way to do this is to make a build which in emscripten replaces indirect calls to a call to a python indirect call trampoline, so that rather than call to fpcast versions, it calls to something in imports which is javascript and does the actual call. I think that side of things would need a change to visitCallIndirect in the binaryen pass to just make it call the javascript trampoline with the signature of the indirect call as a parameter. Then the fpcast trampoline could check that against the signature of what it was calling (using the same , and chuck out a log message if they didn't match. This would be way more efficient if webassembly type reflection was enabled otherwise some manual type reflection cunningness would be needed to get the type of the target. Type reflection is behind a flag in chromium (enable experimental webassembly features).
I imagine it would be slow as a slow thing, but for testing it would do the job I imagine.
I would suggest it isn't much work to update binaryen to call the trampoline, then creating a build that works in chromium with webassembly reflection enabled. It might be that if one can get pyodide itself loading in chromium and run the test suite, that is enough to exercise the code enough to find out what is the cause of the naughty pointer calls and sort it.
I won't have time to do anything till teaching and marking ends (i.e. june/july at earliest), but if anyone wants to do it, I'm happy to input.