Add support for building to the wasm32-wasi target #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ereslibre
force-pushed
the
wasm32-wasi
branch
from
dd07df9 to
37f3d49
Compare
ereslibre
force-pushed
the
wasm32-wasi
branch
from
37f3d49 to
2051af7
Compare
assambar
approved these changes
Jan 26, 2023
There was a problem hiding this comment.
I love this as a first version of the thing. As we discussed offline we should provide more context for the different types of changes and places we needed to change something.
Then maybe a roadmap of what we think should be done next, and asking for opinion on PHP internals on what the community things we should also do, before merging to master.
ereslibre
force-pushed
the
wasm32-wasi
branch
from
2051af7 to
4e53491
Compare
ereslibre
force-pushed
the
wasm32-wasi
branch
3 times, most recently
from
60d61de to
b726faa
Compare
This change performs initial adaptations allowing the PHP interpreter to be compiled for the wasm32-wasi target. Challenges found: - `setjmp`/`longjmp` not available in this platform: can be worked around by using Asyncify; this is work in progress to be presented at a later stage. - Processes: WebAssembly has no concept of processes, so many process-related operations had to be emulated, or are no-ops. `getpid` and clocks are emulated. Signal handling has minimal emulation. `uid`, `gid`, and related concepts that do not map well to a WebAssembly sandbox are also removed. - `mmap` implementation is a minimal emulation that allows to allocate memory or map file contents to it. - Filesystem: many filesystem operations cannot be mapped to WASI, and so these operations are no-ops. - `S_IFSOCK` matches `S_IFIFO` in current `wasi-libc`; removed the `S_IFIFO` case, because `clang` will fail building due to a duplicated constant in `switch` statements. - File locks are also stubbed and always return success. - Networking: given the WebAssembly sandbox and capability-based security, it is not possible to open a socket as of today. Although the host is able to open a socket and forward a file descriptor, leaving the `accept()` syscall to the WebAssembly module, we have removed networking syscalls at this time. The only binary that builds with this change is `php-cgi` at this time. It's possible to adapt the change so that `php` builds and is able to run scripts and programs in the filesystem in a CLI fashion. However, starting a PHP server to listen on a socket using the CLI is a more contrived situation, given it's not possible to open a listening socket from within the sandbox; however it would be possible to create the socket on the host side, and forward the file descriptor to the module. Co-Authored-By: Asen Alexandrov <[email protected]>
ereslibre
force-pushed
the
wasm32-wasi
branch
from
b726faa to
a94519d
Compare
ereslibre
pushed a commit
that referenced
this pull request
Mar 3, 2023
…#10533) Commit a211956 added a TSRM destructor, but that destructor will get called by tsrm_shutdown(), which is after opcache.so has already been unloaded, resulting in a shutdown crash, e.g.: #0 0x00007fad01737500 in ?? () #1 0x000055ac54e723c4 in tsrm_shutdown () at TSRM/TSRM.c:194 #2 0x000055ac54c42180 in main (argc=80, argv=0x55ac57bc14d0) at sapi/cli/php_cli.c:1388 By calling ts_free_id() before opcache.so gets unloaded, we can easily fix this crash bug.
ereslibre
pushed a commit
that referenced
this pull request
Mar 3, 2023
In PHP-2.0 and below we by mistake returned "obcect(FFI\CData:void)#2 (0) {}". We decided not to fix this in PHP-2.0 and below to aboid BC breaks.
ereslibre
pushed a commit
that referenced
this pull request
Mar 3, 2023
In PHP-8.2 and below we by mistake returned "object(FFI\CData:void)#2 (0) {}". We decided not to fix this in PHP-8.2 and below to avoid BC breaks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change performs initial adaptations allowing the PHP interpreter
to be compiled for the wasm32-wasi target.
Challenges found:
setjmp/longjmpnot available in this platform: got acontribution to emulate it in order to run shutdown
functions. Currently working on implementing fibers by emulating
setjmp/longjmp.
Processes: WebAssembly has no concept of processes, so many
process-related operations had to be emulated, or are no-ops.
getpidand clocks are emulated. Signal handling has a minimal
emulation.
uid,gid`, and related concepts that do not map well to aWebAssembly sandbox are also removed.
mmapimplementation is a minimal emulation that allows toallocate empty memory or map file contents to it.
Filesystem: many filesystem operations cannot be mapped to WASI, and
so these operations are no-ops.
S_IFSOCKmatchesS_IFIFOin currentwasi-libc; removed theS_IFIFOcase, becauseclangwill fail building due to aduplicated constant in
switchstatements.Networking: given the WebAssembly sandbox and capability-based
security, it is not possible to open a socket as of today. Although
the host is able to open a socket and forward a file descriptor,
leaving the accept() syscall to the WebAssembly module, we have
no-oped networking syscalls at this time.
Co-Authored-By: Asen Alexandrov [email protected]