Skip to content

Enable all emscripten file systems: IDBFS, NODEFS, PROXYFS and WORKERFS#1596

Merged
hoodmane merged 14 commits intopyodide:mainfrom
bollwyvl:add-idbfs
Jul 16, 2021
Merged

Enable all emscripten file systems: IDBFS, NODEFS, PROXYFS and WORKERFS#1596
hoodmane merged 14 commits intopyodide:mainfrom
bollwyvl:add-idbfs

Conversation

@bollwyvl
Copy link
Copy Markdown
Contributor

@bollwyvl bollwyvl commented May 20, 2021

Elevator Pitch

Enable file system persistence with IndexedDB (IDBFS), Node.js (NODEFS), blobs (WORKERFS), proxy (PROXYFS).

Screenshot from 2021-05-19 23-34-01

Motivation

Continuing the discussion from #328, this would allow a pyodide instance to work more naturally with persistent files.

Some external use cases:

  • persisting files between user sessions
  • sharing files between concurrent browser tabs

Some internal use cases:

  • caching downloaded wheels and API responses?

Changes

  • add -l*fs.js to Makefile to restore all backends
    • considered other backends, but as this has some impact on build time and size without a clear use case, I have not included them for now, but an eventual API should probably plan for supporting them explicitly
  • Expose Module.FS #1692 hoist FS.mount, FS.mkdir and FS.sync and IDBFS up to the pyodide API?
    • rather than doing something fancy, this has the highest likelihood of working with other language runtimes
    • as discussed below, the preferred approach is to hoist FS to the pyodide namespace, pending a better name...
  • add a convenience API in e.g. loadPyodide({mount: "/home/user1"})?
  • tests?
    • haven't looked into what this will take...
  • docs?

Findings

  • you can make as many mount points as you want
  • they all get synced into the MEMFS (which must exist) with FS.sync(true, (err)=>{...}) and likewise back out with FS.sync(false, (err) => {...})
    • the example guidance suggests sync-in at the start of the process and sync-out before exiting, but this is pretty limiting!

Dead-ends

The image above was gotten by hacking main.c, emulating a naive/broken approach for polling. A better path is being investigated!

  // Create and mount userfs immediately.
	EM_ASM({
		FS.mkdir('/home/jo');
		FS.mount(IDBFS, {}, '/home/jo');
    FS.syncfs(true, function (err) {
      err && console.error('error syncing FROM IndexedDB', err);
    });
    setInterval(function() {
        FS.syncfs(false, function (err) {
          err && console.error('error syncing TO IndexedDB', err);
      });
    }, 5000);
	});

@bollwyvl bollwyvl mentioned this pull request May 20, 2021
@bollwyvl
Copy link
Copy Markdown
Contributor Author

With the ba6915e API in place, it works from the console:

Screenshot from 2021-05-20 23-05-18

FF doesn't expose IndexedDB in private browsing, but otherwise seems pretty robust.

@rth
Copy link
Copy Markdown
Member

rth commented May 22, 2021

Thanks for working on this @bollwyvl: very interesting!

One comment: although persistence is definitely something that would be good in some use cases, in others the lack of persistence with MEMFS might be preferable. Or at least more work would be necessary to manage file system state otherwise. For instance, for teaching Python it's appealing to know that users can re-start the tab and restart from from a clean env if necessary. Same for some small demos where there is no need for persistence.

So it might be good to support passing IDBFS as a file_system parameter (with a default to MEMFS) to loadPyodide. Also for Node we would need a different FS anyway.

Another thing I'm curious about is performance. I would imagine that MEMFS would be faster since no actual disk operations need to happen, though it probably also depends on how efficient both implementations are.

@hoodmane
Copy link
Copy Markdown
Member

@rth I think the idea here is that you use MEMFS for everything except some particular directory which is mounted as a persistent directory. I believe that the model supported by Emscripten is: no matter what, the main file system is MEMFS. Inside of MEMFS it is possible to set up directories that sync to other file systems.

@bollwyvl
Copy link
Copy Markdown
Contributor Author

Right, as this PR currently stands, it's an entirely opt-in API, and layers on top of the existing, required MEMFS. It's not even possible to mount to any other *FS to /... perhaps we could provide a more helpful preflight validation error than is presently presented (don't have one handy, but had to go read about it). Similarly, the directory must already exist. But given this is presently more for downstreams, rather than users... even though it is available from the JS console (maybe) and within a pyodide session with import pyodide; pyodide.syncfs, I don't think anyone will be impacted much... aside from the slightly larger builds (haven't measured). If this is an issue, as mentioned in #328, having a second build would be an option.

From a performance perspective: I don't think it's a big driver in the interactive state, as the sync in-and-out is not automagical in any way. A simple usage might choose to only pay the IndexedDB toll (also haven't measured) on startup and shutdown. Of course, on jupyterlite, we're looking to get real crazy with it, so we'd be able to let you know!

@rth
Copy link
Copy Markdown
Member

rth commented May 22, 2021

OK, then great! I missed your example. The size impact seem negligible.

hoist FS.mount, FS.mkdir and FS.sync and IDBFS up to the pyodide API?

Could you elaborate on the motivation there? If we can avoid re-exporting and documenting a significant part of Emscripten's File system API (and use it directly instead) it would be preferable IMO.

@bollwyvl
Copy link
Copy Markdown
Contributor Author

bollwyvl commented May 22, 2021 via email

@hoodmane
Copy link
Copy Markdown
Member

hoodmane commented May 22, 2021

We haven't exposed the emscripten filesystem as a part of our public API. There is desire downstream to be able to directly adjust the filesystem, so I think we should expose it. It would make sense to add FS to the public API, possibly under a clearer name. This should be done as a separate PR before merging this one.

@bollwyvl
Copy link
Copy Markdown
Contributor Author

add FS to the public API, possibly under a clearer name

Sure, that sounds good! I had a look at the typings for emscripten, and they seem widely-used, but pretty out-of-date, but perhaps the @see is the best we can do!

pyodide.Emscripten

Oh, and hiding down at the bottom of the API, i did find pyodide._module 😊 might have to play with that a little downstream to get an idea of what we might be dealing with... though of course IDBFS is not available there... in the meantime, I'll roll back the API changes here, so it's just that one line to the Makefile.

@rth
Copy link
Copy Markdown
Member

rth commented Jul 6, 2021

@bollwyvl Can this be marked as "Ready for review" so it can be merged? Thanks!

@bollwyvl bollwyvl marked this pull request as ready for review July 6, 2021 21:09
@bollwyvl
Copy link
Copy Markdown
Contributor Author

bollwyvl commented Jul 6, 2021

I'll also work up a PR just exposing the as-documented FS API, not sure if that's blocking for this...

@bollwyvl
Copy link
Copy Markdown
Contributor Author

bollwyvl commented Jul 6, 2021

Ar the fails actually indicating anything?

Also, regarding the notional FS PR: I've apparently lost the thread on how to compile the project on a fairly stock ubuntu 20.04... seeing some errors like:

Details
configure: ./configure --host=wasm32-unknown-linux --prefix=~/pyodide/cpython/build/libffi/target --enable-static --disable-shared --disable-dependency-tracking --disable-builddir --disable-multi-os-directory --disable-raw-api
checking build system type... x86_64-pc-linux-gnu
checking host system type... wasm32-unknown-linux-gnu
checking target system type... wasm32-unknown-linux-gnu
checking for gsed... sed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for wasm32-unknown-linux-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for wasm32-unknown-linux-gcc... ~/pyodide/emsdk/emsdk/upstream/emscripten/emcc
checking whether the C compiler works... no
configure: error: in `~/pyodide/cpython/build/libffi':
configure: error: C compiler cannot create executables
See `config.log' for more details
make[1]: *** [Makefile:120: ~/pyodide/cpython/installs/python-3.9.5/lib/libffi.a] Error 77
make[1]: Leaving directory '~/pyodide/cpython'
make: *** [Makefile:205: cpython/installs/python-3.9.5/lib/python3.9] Error 2

where config.log just says configure: exit 77 without anything too out of the ordinary

I don't know enough about the tea leaves to unstick, so would not hold my breath on it for me.

On the up-side: the Emscripten typings were recently updated...

@bollwyvl
Copy link
Copy Markdown
Contributor Author

bollwyvl commented Jul 6, 2021

Ah, more digging:

configure:3862: ~/pyodide/emsdk/emsdk/upstream/emscripten/emcc -O3 -fPIC -DPYODIDE_FPCAST  -L~/pyodide/cpython/build/libffi/target/lib -O3 -s EXPORTED_FUNCTIONS=_main,_malloc,_free -s ALLOW_TABLE_GROWTH conftest.c  >&5
emcc: error: setting `EXPORTED_FUNCTIONS` expects `<class 'list'>` but got `<class 'str'>`

@hoodmane
Copy link
Copy Markdown
Member

hoodmane commented Jul 6, 2021

The CI failures so far are just the normal ones. CircleCi is a bit flakey for us, the webworker tests in particular fail randomly all the time.

Is there a reason you don't want to use the docker image to do the local install? It should prevent these issues. Though it's good for people to try to build natively occasionally so that we can update the instructions.

@hoodmane
Copy link
Copy Markdown
Member

hoodmane commented Jul 6, 2021

What does ~/pyodide/emsdk/emsdk/upstream/emscripten/emcc --version say?

@hoodmane
Copy link
Copy Markdown
Member

hoodmane commented Jul 6, 2021

@bollwyvl
Copy link
Copy Markdown
Contributor Author

bollwyvl commented Jul 7, 2021

haha, would not have found that. This is getting me... further...

diff --git a/cpython/Makefile b/cpython/Makefile
index 4d0399a..2741c4e 100644
--- a/cpython/Makefile
+++ b/cpython/Makefile
@@ -117,7 +117,9 @@ $(INSTALL)/lib/libffi.a :
        rm -rf $(FFIBUILD)
        git clone $(LIBFFIREPO) $(FFIBUILD) --shallow-exclude upstream-base
        source $(PYODIDE_ROOT)/emsdk/emsdk/emsdk_env.sh
-       cd $(FFIBUILD) && git checkout $(LIBFFI_COMMIT) && ./build.sh --pyodide-fpcast && make install
+       cd $(FFIBUILD) && git checkout $(LIBFFI_COMMIT)
+       cd $(FFIBUILD) && sed -i 's/_main,_malloc,_free/["_main","_malloc","_free"]/' build.sh
+       cd $(FFIBUILD) && ./build.sh --pyodide-fpcast && make install
        cp $(FFIBUILD)/target/include/*.h $(BUILD)/Include/
        mkdir -p $(INSTALL)/lib
        cp $(FFIBUILD)/target/lib/libffi.a $(INSTALL)/lib/

hoodmane pushed a commit to hoodmane/libffi-emscripten that referenced this pull request Jul 7, 2021
@bollwyvl bollwyvl mentioned this pull request Jul 7, 2021
5 tasks
@bollwyvl
Copy link
Copy Markdown
Contributor Author

bollwyvl commented Jul 7, 2021

#1692 is up, with the strawman API name of fileSystem

@bollwyvl
Copy link
Copy Markdown
Contributor Author

bollwyvl commented Jul 7, 2021

Is there a reason you don't want to use the docker image to do the local install? It should prevent these issues.

Yeah, I have to deal with all kinds of container junk at $DAY_JOB, and try to stay pretty clear of it until I need:

  • something very custom in CI
  • helm

Though it's good for people to try to build natively occasionally so that we can update the instructions.

Welp, anytime PRs comes from me, they'll at least have sorta built locally, once! I generally try to make the conda-forge stack work unless I get very deep into weird things, and indeed, reckon CF and condadide/mambadide will eventually provide immense value...

@bollwyvl
Copy link
Copy Markdown
Contributor Author

Set it to FS. As a light indicator, the ipdfs test reads a bit more nicely.

@bollwyvl
Copy link
Copy Markdown
Contributor Author

Down to just core-firefox flaking... guess I'd call that a win!

@hoodmane
Copy link
Copy Markdown
Member

Yup CI is doing good enough to merge now if it passes review. You have only 4/6 checks marked, you want this reviewed? A convenience API could probably be added later, might be nice to have something in the docs about this stuff though.

@bollwyvl
Copy link
Copy Markdown
Contributor Author

A convenience API could probably be added later,

Sure, closed that out and opened a ticket.

@bollwyvl
Copy link
Copy Markdown
Contributor Author

have something in the docs about this stuff though.

As mentioned... I haven't been able to play with the API much, but will... once there are nightlies with persistence. It'll be a lot easier for me to start rapping on examples once I've fought some of our (self-made) problems on jupyterlite. As it is, the API should have fairly good SEO with FS... i had to learn it all by digging around in Other People's Code, anyhow!

To that end, is there a "fast path" for docs-only PRs that wouldn't invoke the entire CI pipeline?

@hoodmane
Copy link
Copy Markdown
Member

hoodmane commented Jul 14, 2021

Putting [skip ci] in the commit message won't invoke the pipeline.

@hoodmane
Copy link
Copy Markdown
Member

hoodmane commented Jul 14, 2021

Right updating the docs later makes sense to me. Not much harm in having a feature that nobody knows about for a little while. I guess the fear is that if people get the features they want added in they may never actually come back to update the docs.

@bollwyvl
Copy link
Copy Markdown
Contributor Author

people get the features they want added in they may never actually come back

don't i know it, friend! I added a note to that effect: #1715. Basically, it would be my preference if we could get some idea of what people might do with it (after doing some of it) the Hard Way, make a better API (especially for people actually using pyodide-flavored python) and land it here, rather than trying to do it our darned selves on lite. Semi-related: we might have to do some %pip stuff (to maintain parity with our other upstream), but the hope would be to rapidly turn them there, get feedback from our deployers, then take the lessons learned and propose them to micropip... so we don't have to maintain them.

@bollwyvl
Copy link
Copy Markdown
Contributor Author

So i guess i've argued myself out of the last two bullets, so this is probably ready for review!

@hoodmane
Copy link
Copy Markdown
Member

Okay I'll take a look when I have time.

@hoodmane
Copy link
Copy Markdown
Member

If you resolve the merge conflict I will merge this.

@bollwyvl
Copy link
Copy Markdown
Contributor Author

I'm still having some issues with the node-based tests locally, but everything else appears fine, locally 😁. Here's hoping!

@bollwyvl
Copy link
Copy Markdown
Contributor Author

ha, I'll take it:

warning: no blob constructor, cannot create blobs with mimetypes
warning: no BlobBuilder
Python initialization complete
Loading distutils
Loading distutils from ../../build/distutils.js
Loaded distutils
  FS
    ✔ no dir (96ms)
    ✔ mkdir
    ✔ made dir (81ms)

  Module
    noWasmDecoding
      ✔ should be false 

  Pyodide
    ✔ runPython
Loading micropip, pyparsing, packaging, distutils
Loading micropip from ../../build/micropip.js
Loading pyparsing from ../../build/pyparsing.js
Loading packaging from ../../build/packaging.js
distutils already loaded from default channel
Loaded micropip, pyparsing, packaging, distutils
    ✔ loadPackage (205ms)
    ✔ micropip.install (1664ms)


  7 passing (16s)


@hoodmane hoodmane merged commit f13f334 into pyodide:main Jul 16, 2021
@bollwyvl
Copy link
Copy Markdown
Contributor Author

bollwyvl commented Jul 16, 2021 via email

@hoodmane
Copy link
Copy Markdown
Member

Thanks for contributing!

@sylvain-ri
Copy link
Copy Markdown
Contributor

Guys I can just say that you are doing some magic here 😁
Thanks for developing pyodide, i wished i understand enough to contribute.

atgreen pushed a commit to libffi/libffi that referenced this pull request Feb 2, 2023
* added build script

* Apply libffi-emscripten patch

* Some changes to wasm32/ffi.c

* Remove exit(0); from test suites

* Fix LONGDOUBLE argument type

* Use more macros in ffi.c

* Use switch statements instead of if chains

* Implemented struct args

* Finish struct implementation

* Partially working closures

* Got closures working (most of closures test suite passes)

* Revert changes to test suite

* Update .gitignore

* Apply code formatter

* Use stackSave and stackRestore rather than directly adjusting stack pointer

* Add missing break

* Fix visibility of ffi_closure_alloc and ffi_closure_free

* Fix FFI_TYPE_STRUCT and FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used
sig needs to be vi here for FFI_TYPE_STRUCT and FFI_TYPE_LONGDOUBLE, noticed this while running the test suite without WASM_BIGINT support.

* Always use dynCall rather than direct wasmTable lookup (function pointer cast emulation changes dynCall)

* Prevent closures.c from duplicating symbols

* Try to set up CI

* Add test with bigint

* Make test methods static

* Remove BigInt shorthand because it messes up terser

* Add selenium tests

* Update tests a bit to try to make CI work

* WASM_BIGINT is a linker flag not a compile flag

* Finish getting CI working (#1)

* update gitignore

* Avoid adding "use strict;" to generated JS

This should be controlled by -s STRICT_JS in Emscripten.

* Make JavaScript ES5 compliant

* Remove redundant EXPORTED_RUNTIME_METHODS settings

* Fix definition of DEREF_I16

* Avoid marshalling FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used

* Add missing FFI_TYPE_STRUCT signature

* Improve test scripts

* Remove redundant EXPORTED_RUNTIME_METHODS settings

* Add missing EOL

* Add struct unpacking tests

* Update ci config to try to actually use WASM_BIGINT

* Revert "Avoid marshalling FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used"

This reverts commit 61bd5a3.

* Fix single_entry_structs tests

* Fix return from closure call

* Fix 64 bit return from closures

* only allocate as much space on stack for return pointer as needed

* Revert "only allocate as much space on stack for return pointer as needed"

This reverts commit e54a30f.

* xfail two tests

* Fix err_bad_abi test

* Remove test logging junk

* Try to set up long double marshalling for closures

* xfail err_bad_abi

* Fix reference errors in previous commit

* Add missing argument pointer assignment

* Fix signature of function pointer in cls_dbls_struct

* Fix longdouble argument

* Try some changes to bigint handling

* Fix BigInt handling

* Fix cls_longdouble test

* Fix long double closure arg with no WASM_BIGINT

* Use EM_JS to factor out js helpers

* Support for varargs closure calls

* Fix varargs calls

* Fix err_bad_abi test

* Fix typo in previous commit

* Add more assertions to closures test suite

* Fix some asserts

* Add assertions to a few more tests

* Fix some tests

* Fix more floating point assertions

* Update more tests

* Var args for ffi_call

* Don't do node tests

* Macro for allocating on stack

* Add some comments, simplify struct handling

* Try again to fix varargs calls, add comments

* Consolidate WASM_BIGINT conditionals into LOAD_U64 and STORE_U64 macros

* A bit of cleanup

* Fix another typo

* Some fixes to the testsuite

* Another testsuite fix

* Fix varags with closures?

* Another attempt at getting closure varargs to work

* sig is initialized later

* Allow libffi.closures tests to be run

* Improve build script

* Remove redundant semicolons

* Fix a few libffi.closures test failures

* Cleanup

* Legacy dynCall API is no longer used

* Fix FFI_TYPE_LONGDOUBLE offset

* xfail 2 tests for WASM

- closure_loc_fn0; not applicable -- codeloc doesn't point to closure.
- huge_struct; function signature too long.

* Revert some redundant dg-output/printf statements

Helps Node.

* Revert "Don't do node tests"

This reverts commit a341ef4.

* Fix assertions in cls_24byte

* More tiny formating fixes to test suite

* Revert "Revert "Don't do node tests""

This reverts commit 7722e68.

* Fix 64 bit returns when WASM_BIGINT is absent

* Fix print statement in cls_24byte

* Add CALL_FUNC_PTR macro to allow pyodide to define custom calling behavior to handle fpcast

* Update single_entry_structs tests

* More explanations

* Fix compile error in last commit

* Add more support for pyodide fpcast emulation, update CI to try to test it

* Clone via https

* Fix path to pyodide emsdk_env

* Add asserts to the rest of the test suite

* Fix test compile errors

* Fix some tests

* Fix cls_ulonglong

* Fix alignment of <4 byte args

* fix cls_ulonglong again

* Use snprintf instead of sprintf

* Should assert than strncmp returned 0

* Fix va_struct1 and va_struct3

* Change double and long double tests

These tests are failing because of a strange bug with prinft and doubles, but I am not convinced
it necessarily has anything to do with libffi. This version casts the double to int before printing it and avoids the issue

* Enable node tests

* Revert "Change double and long double tests"

This reverts commit 8f3ff89.

* Fix PYODIDE_FPCAST flag

* add conftest.py back in

* Fix emcc error: setting `EXPORTED_FUNCTIONS` expects `<class 'list'>` but got `<class 'str'>`

See discussion on pyodide/pyodide#1596

* Remove test.html

* Remove duplicate test file

* More changes from upstream

* Fix some whitespace

* Add some basic debug logging statements

* Reapply libffi.exp changes

* Don't build docs (#7)

Works around build issue makeinfo: command not found.

* Update long double alignment

Emscripten 2.0.26 reduces the aligmnet of long double to 8. Quoting
from `ChangeLog.md`:

> The alignment of `long double`, which is a 128-bit floating-point
> value implemented in software, is reduced from 16 to 8. The lower
> alignment allows `max_align_t` to properly match the alignment we
> use for malloc, which is 8 (raising malloc's alignment to achieve
> correctness the other way would come with a performance regression).
> (#10072)

* Update long double alignment

Emscripten 2.0.26 reduces the aligmnet of long double to 8. Quoting
from `ChangeLog.md`:

> The alignment of `long double`, which is a 128-bit floating-point
> value implemented in software, is reduced from 16 to 8. The lower
> alignment allows `max_align_t` to properly match the alignment we
> use for malloc, which is 8 (raising malloc's alignment to achieve
> correctness the other way would come with a performance regression).
> (#10072)

* Improve error handling a bit (#8)

* Fix handling of signed arguments to ffi_call (#11)

* Fix struct argument handling in ffi_call (#10)

* Remove fpcast emulation tests

* Align the stack to MAX_ALIGN before making call (#12)

* Increase MAX_ARGS

* Cleanup (#14)

* Fix Closure compiler error with -sASSERTIONS=1 (#15)

* Remove function pointer cast emulation (#13)

This reverts commit 593b402 and cbc54da, as it's no longer needed
after PR pyodide/pyodide#2019.

* Prefer the `__EMSCRIPTEN__` definition over `EMSCRIPTEN` (#18)

"The preprocessor define EMSCRIPTEN is deprecated. Don't pass it to code
in strict mode. Code should use the define __EMSCRIPTEN__ instead."
https://github.com/emscripten-core/emscripten/blob/84a634167a1cd9e8c47d37a559688153a4ceace6/emcc.py#L887-L890

* Install autoconf 2.71

* Try again with installing autoconf 2.71

* Fix compatibility with Emscripten 3.1.28

* CI: remove use of `EM_CONFIG` env

See commit:
emscripten-core/emsdk@3d87d5e

* Fix cls_multi_schar: cast rest_call to signed char

* Remove test xfails (#17)

* Fix long double when used as a varargs argument

* Enable unwindtest and fix it

* Add EM_JS_DEPS

* Also require convertJsFunctionToWasm

* Run tests very very verbose

* Echo the .emscripten file

* Remove --experimental-wasm-bigint insertion

* Build with assertions

* Move verbosity flags back out of LDFLAGS

* Remove debug print statement

* Use up to date pyodide docker image

* Explicitly cast res_call to fix test failure

* Put back name of main function in cls_longdouble_va.c

* Fix alignment

The stack pointer apparently needs to be aligned to 16. There were
some terrible subtle bugs caused by not respecting this. stackAlloc
knows that the stack should be 16 aligned, so we can use stackAlloc(0)
to enforce this. This way if alignment requirements change, as long
as Emscripten updates stackAlloc to continue to enforce them we should
be okay.

* Fix handling of systems with no Js bigint integration

When we run the node tests we use node v14 tests (since node v14 is
vendored with Emscripten). Node v14 has no Js bigint integration
unless the --experimental-wasm-bigint flag is passed. So only the
node tests really notice if we get this right. Turns out, it didn't
work. We can't call a JavaScript function with 64 bit integer arguments
without bigint integration.

In ffi_call, we are trying to call a wasm function that takes 64 bit
integer arguments. dynCall is designed to do this. We need to go back
to tracking the signature when we don't have WASM_BIGINT, and then use
dynCall. This works better now that emscripten can dynamically fill in
extra dynCall wrappers:
emscripten-core/emscripten#17328

On the other hand, for the closures we are not getting a function pointer
as a first argument. We need to make our own wasm legalizer adaptor that
splits 64 bit integer arguments and then calls the JavaScript trampoline,
then the JavaScript trampoline reassembles them, calls the closure, then
splits the result (if it's a 64 bit integer) and the adaptor puts it back
together.

* Improvements to emscripten test shell scripts (#21)

This fixes the C++ unwinding tests and makes other minor improvements
to the Emscripten test shell scripts.

* Rename the test folder and move test files into emscripten test folder

* Use docker image that has autoconf-2.71

* Cleanup

* Pin emscripten 3.1.30

* Fix build.sh path

* Rearrange ci pipeline

* Fix bpo_38748 test

* Cleanup

* Improvements to comments, add static asserts, and update copyright

* Use `*_js` instead of `*_helper` for EM_JS functions (#22)

* Minor code simplification

* Xfail first dejagnu test to work around emscripten cache messages

See emscripten-core/emscripten#18607

* Remove unneeded xfails

* Shorten conftest.py by using pytest-pyodide

* Apply formatters and linters to emscripten directory

* Fix Emscripten xfail hack

* Fix build-tests script

* Patch emscripten to quiet info messages

* Clean up compiler flags in scripts and remove some settings from circleci config

* Rename emscripten quiet script

* Add missing export

* Don't remove go.exp

* Add reference to emscripten logging issue

---------

Co-authored-by: Kleis Auke Wolthuizen <[email protected]>
Co-authored-by: Kleis Auke Wolthuizen <[email protected]>
Co-authored-by: Christian Heimes <[email protected]>
Assioftware added a commit to Assioftware/libffi that referenced this pull request Feb 5, 2023
* added build script

* Apply libffi-emscripten patch

* Some changes to wasm32/ffi.c

* Remove exit(0); from test suites

* Fix LONGDOUBLE argument type

* Use more macros in ffi.c

* Use switch statements instead of if chains

* Implemented struct args

* Finish struct implementation

* Partially working closures

* Got closures working (most of closures test suite passes)

* Revert changes to test suite

* Update .gitignore

* Apply code formatter

* Use stackSave and stackRestore rather than directly adjusting stack pointer

* Add missing break

* Fix visibility of ffi_closure_alloc and ffi_closure_free

* Fix FFI_TYPE_STRUCT and FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used
sig needs to be vi here for FFI_TYPE_STRUCT and FFI_TYPE_LONGDOUBLE, noticed this while running the test suite without WASM_BIGINT support.

* Always use dynCall rather than direct wasmTable lookup (function pointer cast emulation changes dynCall)

* Prevent closures.c from duplicating symbols

* Try to set up CI

* Add test with bigint

* Make test methods static

* Remove BigInt shorthand because it messes up terser

* Add selenium tests

* Update tests a bit to try to make CI work

* WASM_BIGINT is a linker flag not a compile flag

* Finish getting CI working (#1)

* update gitignore

* Avoid adding "use strict;" to generated JS

This should be controlled by -s STRICT_JS in Emscripten.

* Make JavaScript ES5 compliant

* Remove redundant EXPORTED_RUNTIME_METHODS settings

* Fix definition of DEREF_I16

* Avoid marshalling FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used

* Add missing FFI_TYPE_STRUCT signature

* Improve test scripts

* Remove redundant EXPORTED_RUNTIME_METHODS settings

* Add missing EOL

* Add struct unpacking tests

* Update ci config to try to actually use WASM_BIGINT

* Revert "Avoid marshalling FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used"

This reverts commit 61bd5a3e20891623715604581b6e872ab3dfab80.

* Fix single_entry_structs tests

* Fix return from closure call

* Fix 64 bit return from closures

* only allocate as much space on stack for return pointer as needed

* Revert "only allocate as much space on stack for return pointer as needed"

This reverts commit e54a30faea3803e7ac33eed191bde9e573850fc1.

* xfail two tests

* Fix err_bad_abi test

* Remove test logging junk

* Try to set up long double marshalling for closures

* xfail err_bad_abi

* Fix reference errors in previous commit

* Add missing argument pointer assignment

* Fix signature of function pointer in cls_dbls_struct

* Fix longdouble argument

* Try some changes to bigint handling

* Fix BigInt handling

* Fix cls_longdouble test

* Fix long double closure arg with no WASM_BIGINT

* Use EM_JS to factor out js helpers

* Support for varargs closure calls

* Fix varargs calls

* Fix err_bad_abi test

* Fix typo in previous commit

* Add more assertions to closures test suite

* Fix some asserts

* Add assertions to a few more tests

* Fix some tests

* Fix more floating point assertions

* Update more tests

* Var args for ffi_call

* Don't do node tests

* Macro for allocating on stack

* Add some comments, simplify struct handling

* Try again to fix varargs calls, add comments

* Consolidate WASM_BIGINT conditionals into LOAD_U64 and STORE_U64 macros

* A bit of cleanup

* Fix another typo

* Some fixes to the testsuite

* Another testsuite fix

* Fix varags with closures?

* Another attempt at getting closure varargs to work

* sig is initialized later

* Allow libffi.closures tests to be run

* Improve build script

* Remove redundant semicolons

* Fix a few libffi.closures test failures

* Cleanup

* Legacy dynCall API is no longer used

* Fix FFI_TYPE_LONGDOUBLE offset

* xfail 2 tests for WASM

- closure_loc_fn0; not applicable -- codeloc doesn't point to closure.
- huge_struct; function signature too long.

* Revert some redundant dg-output/printf statements

Helps Node.

* Revert "Don't do node tests"

This reverts commit a341ef4b.

* Fix assertions in cls_24byte

* More tiny formating fixes to test suite

* Revert "Revert "Don't do node tests""

This reverts commit 7722e685ea04e2420e042886816d8c4dd31f5dcb.

* Fix 64 bit returns when WASM_BIGINT is absent

* Fix print statement in cls_24byte

* Add CALL_FUNC_PTR macro to allow pyodide to define custom calling behavior to handle fpcast

* Update single_entry_structs tests

* More explanations

* Fix compile error in last commit

* Add more support for pyodide fpcast emulation, update CI to try to test it

* Clone via https

* Fix path to pyodide emsdk_env

* Add asserts to the rest of the test suite

* Fix test compile errors

* Fix some tests

* Fix cls_ulonglong

* Fix alignment of <4 byte args

* fix cls_ulonglong again

* Use snprintf instead of sprintf

* Should assert than strncmp returned 0

* Fix va_struct1 and va_struct3

* Change double and long double tests

These tests are failing because of a strange bug with prinft and doubles, but I am not convinced
it necessarily has anything to do with libffi. This version casts the double to int before printing it and avoids the issue

* Enable node tests

* Revert "Change double and long double tests"

This reverts commit 8f3ff89c6577dc99564181cd9974f2f1ba21f1e9.

* Fix PYODIDE_FPCAST flag

* add conftest.py back in

* Fix emcc error: setting `EXPORTED_FUNCTIONS` expects `<class 'list'>` but got `<class 'str'>`

See discussion on pyodide/pyodide#1596

* Remove test.html

* Remove duplicate test file

* More changes from upstream

* Fix some whitespace

* Add some basic debug logging statements

* Reapply libffi.exp changes

* Don't build docs (#7)

Works around build issue makeinfo: command not found.

* Update long double alignment

Emscripten 2.0.26 reduces the aligmnet of long double to 8. Quoting
from `ChangeLog.md`:

> The alignment of `long double`, which is a 128-bit floating-point
> value implemented in software, is reduced from 16 to 8. The lower
> alignment allows `max_align_t` to properly match the alignment we
> use for malloc, which is 8 (raising malloc's alignment to achieve
> correctness the other way would come with a performance regression).
> (#10072)

* Update long double alignment

Emscripten 2.0.26 reduces the aligmnet of long double to 8. Quoting
from `ChangeLog.md`:

> The alignment of `long double`, which is a 128-bit floating-point
> value implemented in software, is reduced from 16 to 8. The lower
> alignment allows `max_align_t` to properly match the alignment we
> use for malloc, which is 8 (raising malloc's alignment to achieve
> correctness the other way would come with a performance regression).
> (#10072)

* Improve error handling a bit (#8)

* Fix handling of signed arguments to ffi_call (#11)

* Fix struct argument handling in ffi_call (#10)

* Remove fpcast emulation tests

* Align the stack to MAX_ALIGN before making call (#12)

* Increase MAX_ARGS

* Cleanup (#14)

* Fix Closure compiler error with -sASSERTIONS=1 (#15)

* Remove function pointer cast emulation (#13)

This reverts commit 593b402 and cbc54da, as it's no longer needed
after PR pyodide/pyodide#2019.

* Prefer the `__EMSCRIPTEN__` definition over `EMSCRIPTEN` (#18)

"The preprocessor define EMSCRIPTEN is deprecated. Don't pass it to code
in strict mode. Code should use the define __EMSCRIPTEN__ instead."
https://github.com/emscripten-core/emscripten/blob/84a634167a1cd9e8c47d37a559688153a4ceace6/emcc.py#L887-L890

* Install autoconf 2.71

* Try again with installing autoconf 2.71

* Fix compatibility with Emscripten 3.1.28

* CI: remove use of `EM_CONFIG` env

See commit:
emscripten-core/emsdk@3d87d5e

* Fix cls_multi_schar: cast rest_call to signed char

* Remove test xfails (#17)

* Fix long double when used as a varargs argument

* Enable unwindtest and fix it

* Add EM_JS_DEPS

* Also require convertJsFunctionToWasm

* Run tests very very verbose

* Echo the .emscripten file

* Remove --experimental-wasm-bigint insertion

* Build with assertions

* Move verbosity flags back out of LDFLAGS

* Remove debug print statement

* Use up to date pyodide docker image

* Explicitly cast res_call to fix test failure

* Put back name of main function in cls_longdouble_va.c

* Fix alignment

The stack pointer apparently needs to be aligned to 16. There were
some terrible subtle bugs caused by not respecting this. stackAlloc
knows that the stack should be 16 aligned, so we can use stackAlloc(0)
to enforce this. This way if alignment requirements change, as long
as Emscripten updates stackAlloc to continue to enforce them we should
be okay.

* Fix handling of systems with no Js bigint integration

When we run the node tests we use node v14 tests (since node v14 is
vendored with Emscripten). Node v14 has no Js bigint integration
unless the --experimental-wasm-bigint flag is passed. So only the
node tests really notice if we get this right. Turns out, it didn't
work. We can't call a JavaScript function with 64 bit integer arguments
without bigint integration.

In ffi_call, we are trying to call a wasm function that takes 64 bit
integer arguments. dynCall is designed to do this. We need to go back
to tracking the signature when we don't have WASM_BIGINT, and then use
dynCall. This works better now that emscripten can dynamically fill in
extra dynCall wrappers:
emscripten-core/emscripten#17328

On the other hand, for the closures we are not getting a function pointer
as a first argument. We need to make our own wasm legalizer adaptor that
splits 64 bit integer arguments and then calls the JavaScript trampoline,
then the JavaScript trampoline reassembles them, calls the closure, then
splits the result (if it's a 64 bit integer) and the adaptor puts it back
together.

* Improvements to emscripten test shell scripts (#21)

This fixes the C++ unwinding tests and makes other minor improvements
to the Emscripten test shell scripts.

* Rename the test folder and move test files into emscripten test folder

* Use docker image that has autoconf-2.71

* Cleanup

* Pin emscripten 3.1.30

* Fix build.sh path

* Rearrange ci pipeline

* Fix bpo_38748 test

* Cleanup

* Improvements to comments, add static asserts, and update copyright

* Use `*_js` instead of `*_helper` for EM_JS functions (#22)

* Minor code simplification

* Xfail first dejagnu test to work around emscripten cache messages

See emscripten-core/emscripten#18607

* Remove unneeded xfails

* Shorten conftest.py by using pytest-pyodide

* Apply formatters and linters to emscripten directory

* Fix Emscripten xfail hack

* Fix build-tests script

* Patch emscripten to quiet info messages

* Clean up compiler flags in scripts and remove some settings from circleci config

* Rename emscripten quiet script

* Add missing export

* Don't remove go.exp

* Add reference to emscripten logging issue

---------

Co-authored-by: Kleis Auke Wolthuizen <[email protected]>
Co-authored-by: Kleis Auke Wolthuizen <[email protected]>
Co-authored-by: Christian Heimes <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants