| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
There were a couple of places where we were relying on internal
names and therefore a name section. After this change
wasm-emscripten-finalize works correctly on binaries without a name
section at all and only relies on the names of imports and exports.
|
| |
|
|
|
|
|
| |
This reverts commit 692f4666fd116fb7827b53348978f29bba253d47.
See details in the reverted PR.
|
|
|
|
|
| |
This fix does not handle dynamic linking, which requires additional work.
Refs https://github.com/emscripten-core/emscripten/issues/8894.
|
|
|
|
|
|
|
| |
The new flag indicates whether main reads the argc/argv parameters. If it does not, we can avoid emitting code to generate those arguments in the JS, which is not trivial in small programs - it requires some string conversion code.
Nicely the existing test inputs were enough for testing this (see outputs).
This depends on an emscripten change to land first, as emscripten.py asserts on metadata fields it doesn't recognize.
|
|
|
|
|
| |
The key thing is that there is a single constant, which may or may not be saved/loaded from a local, and may or may not get an added global if in relocatable code.
Fixes emscripten-core/emscripten#8993
|
| |
|
|
|
| |
This is core import like __memory_base and __table_base.
|
|
|
|
|
|
|
|
|
|
|
| |
I'm working on a change to lld that will cause `-pie` binaries to
import __stack_pointer, just like -shared do already. Because we
don't yet support mutable globals everywhere this change will
internalize the import and create a new immutable import that is used
to initialize the internal one.
This change is part of the fix for:
https://github.com/emscripten-core/emscripten/issues/8915
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were passing bad value in --initial-stack-pointer which did not
include the STATIC_BUMP (since STATIC_BUMP is determinted by the output
of finalize).
If emscripten wants to set the stack pointer position it can do
so by calling the stackRestore() function at startup.
This argument will be removed completely once we stop passing it on the
emscripten side.
See https://github.com/emscripten-core/emscripten/issues/8905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Reflected new renamed instruction names in code and tests:
- `get_local` -> `local.get`
- `set_local` -> `local.set`
- `tee_local` -> `local.tee`
- `get_global` -> `global.get`
- `set_global` -> `global.set`
- `current_memory` -> `memory.size`
- `grow_memory` -> `memory.grow`
- Removed APIs related to old instruction names in Binaryen.js and added
APIs with new names if they are missing.
- Renamed `typedef SortedVector LocalSet` to `SetsOfLocals` to prevent
name clashes.
- Resolved several TODO renaming items in wasm-binary.h:
- `TableSwitch` -> `BrTable`
- `I32ConvertI64` -> `I32WrapI64`
- `I64STruncI32` -> `I64SExtendI32`
- `I64UTruncI32` -> `I64UExtendI32`
- `F32ConvertF64` -> `F32DemoteI64`
- `F64ConvertF32` -> `F64PromoteF32`
- Renamed `BinaryenGetFeatures` and `BinaryenSetFeatures` to
`BinaryenModuleGetFeatures` and `BinaryenModuleSetFeatures` for
consistency.
|
| |
|
|
|
|
|
|
|
|
|
| |
(#2095)
Previously we were only creating `dynCall` functions for signatures
that we have statically in the table. However for dynamic linking we
may need to invoke functions that we don't have table entries for
(e.g. table entries from a different module).
|
|
|
| |
Applies the changes in #2065, and temprarily disables the hook since it's too slow to run on a change this large. We should re-enable it in a later commit.
|
|
|
|
| |
EmscriptenGlueGenerator::separateDataSegments (#2068)
|
|
|
| |
Mass change to apply clang-format to everything. We are applying this in a PR by me so the (git) blame is all mine ;) but @aheejin did all the work to get clang-format set up and all the manual work to tidy up some things to make the output nicer in #2048
|
|
|
|
|
| |
As well as i64 splitting this pass was also converting f32 to f64
at the wasm boundry. However it appears this is not actually useful
and makes somethings (such as dynamic linking) harder.
|
|
|
|
|
|
|
|
|
| |
When replacing the first argument to an asm call, allow more complex
expressions for expressing the address.
This fixes the case where the first argument might be the result
of adding a constant to __memory_base.
|
|
|
|
|
| |
In the absence of the target features section or command line flags. When there are command line flags, it is an error if they do not exactly match the target features section, except if --detect-features has been provided.
Also adds a --print-features pass to print the command line flags for all enabled options and uses it to make the feature tests more rigorous.
|
|
|
|
|
|
|
|
| |
Previously we were searching for the function by name but this
doesn't work when the internal name for the function is different.
In order to repro such a case the shared.c test was converted to C++
since then binaryen's internal name is different since it comes from
the de-mangled name section.
|
|
|
|
|
| |
This allows us to emit a (potentially modified) target features
section and conditionally emit other sections such as the DataCount
section based on the presence of features.
|
|
|
|
|
|
| |
In relocatable code the constant offset might be relative to
__memory_base.
|
|
|
|
|
|
|
|
| |
Turns out there was already a precedent in emscripten for using
`fp$` for these functions.
Also, improve the heuristics for guessing the stack pointer global.
There are cases where we don't use have an explicit stack pointer at
all but *do* have both imported and exported globals.
|
|
|
|
|
| |
Adds support for the bulk memory proposal's passive segments. Uses a
new (data passive ...) s-expression syntax to mark sections as
passive.
|
| |
|
|
|
| |
Emscripten runs wasm-emscripten-finalize before running wasm-opt, so the target features section is stripped out before optimizations are run. One option would have been to add another wasm-opt invocation at the very end to strip the target features section, but dumping the features as metadata avoids the extra tool invocation. In the long run, it would be nice to have only as single binaryen invocation to do all the work that needs doing.
|
|
|
|
|
|
| |
This key is used by emscripten when building with MAIN_MODULE in order
to export global variables from the main module to the side modules.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert PIC code generated by llvm to work with the current emscripten
ABI for dynamic linking:
- Convert mutable global imports from GOT.mem and GOT.func into
internal globals.
- Initialize these globals on started up in g$foo and f$foo imported functions
to calculate addresses at runtime.
Also:
- Add a test case for linking and finalizing a shared library
- Allow __stack_pointer global to be non-existent as can be case for
a shared library.
- Allow __stack_pointer global to be an import, as can be the case for
a shared library.
|
|
|
|
|
|
|
|
|
| |
(#1944)
We expect the stack pointer to be of a certain type. This fixes
a segfault we are seeing when passed a binary which doesn't quite
meet our expectations.
|
|
|
|
| |
We now implement addFunction by creating a wasm module to wrap
that JS function and simply adding it to the table.
|
|
|
|
|
| |
This can happen in emscripten if we run fpcast-emu after previous passes created dynCalls already. If so, it's fine to just do nothing.
Fixes emscripten-core/emscripten#8229
|
| |
|
|
|
|
|
| |
We should emit a file with only the data segments, starting from the global base, and not starting from zero (the data before is unneeded, and the emscripten loading code assumes it isn't there).
Also fix the auto updater to work properly on .mem test updating.
|
|
|
| |
Before this, we just did not emit illegal dynCalls. This was wrong as we do need them (e.g. if a function with a setjmp call calls a function with an i64 param - we'll have an invoke with that signature there). We just need to legalize them. This fixes that by first emitting them, and second by running legalization late, after dynCalls have been generated, so it legalizes them too.
|
|
|
|
|
|
|
| |
See emscripten-core/emscripten#7928 - we have been optimizing all wasms until now, and noticed this when the wasm object file path did not do so. When not optimizing, our methods of handling EM_ASM and EM_JS fail since the patterns are different.
Specifically, for EM_ASM we hunt for emscripten_asm_const(X, where X is a constant, but without opts it may be a get of a local. For EM_JS, the function body may not just contain a const, but a block with a set of the const and a return of a get later.
This adds logic to track gets and sets in basic blocks, which is sufficient to handle this.
|
|
|
|
|
|
| |
This takes advantage of the recent memory simplification in emscripten, where JS static allocation is done at compile time. That means we know the stack's initial location at compile time, and can apply it. This is the binaryen side of that:
* asm2wasm support for asm.js globals with an initial value var X = Y; where Y is not 0 (which is what the stack now is).
* wasm-emscripten-finalize support for a flag --initial-stack-pointer=X, and remove the old code to import the stack's initial location.
|
|
|
|
|
|
|
| |
(#1828)
This fixes a crash where startSave/stackRestore could be created
while iterating through `module.functions`.
|
|
|
|
| |
This allows emscripten to generate table of the correct size.
Right now is simply defaults to creating a table to size 1024.
|
|
|
|
|
|
| |
input (#1825)
|
| |
|
| |
|
|
|
| |
And use it in wasm-emscripten
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The wasm backend uses a wasm global (__stack_pointer) for the shadow
stack location. In order to make this work with shared libraries the
main module would have to export this global and shared libraries would
need to import it. This means we'd be relying of mutable globals which
are not yet implemented in all browsers.
This change allows is to move forward with shared libraries without
mutable global support by replacing all stack pointer access in shared
libraries with functions calls.
|
|
|
|
| |
In this case we won't want generate any of the normal memory
helper functions (they come from the main module).
|
|
|
|
|
| |
Not at all sure why we're seeing any there, but it's easy enough to
handle that we might as well.
|
|
|
|
| |
This writes the data section into a file suitable for use with emscripten's
--memory-init-file flag
|
|
|
|
| |
actual support) (#1711)
|
|
|
| |
While debugging to fix the waterfall regressions I noticed that wasm-reduce regressed. We need to be more careful with visitFunction which now may visit an imported function - I found a few not-well-tested passes that also regressed that way.
|
|
|
| |
Fixes the 3 regressions mentioned in a comment on #1678
|