| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
When minimizing wasm changes, leave it as __indirect_function_table
which is what LLVM emits.
This also removes the renaming of the memory. That was never needed
as LLVM already emits "memory" there.
See #3043
|
| |
|
|
|
|
| |
Two new flags here, one to completely removes dynCalls, and another to
limit them to only signatures that contains i64.
See #3043
|
| |
|
|
|
|
|
| |
The minimizeWasmChanges flag now does nothing (but new changes are
coming, so keep it around) - this moves us to always doing the new way of
things. With that we can update the tests.
See #3043
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
wasm-emscripten-finalize renames EM_ASM calls to have the signature in
the name. This isn't actually useful - emscripten doesn't benefit from that. I
think it was optimized in fastcomp, and in upstream we copied the general
form but not the optimizations, and then EM_JS came along which is
easier to optimize anyhow.
This PR makes those changes optional: when not doing them, it just
leaves the calls as they are. Emscripten will need some changes to
handle that, but those are simple.
For convenience this adds a flag to "minimize wasm changes". The idea
is that this flag avoids needing a double-roll or other inconvenience
as the changes need to happen in tandem on the emscripten side.
The same flag can be reused for later changes similar to this one.
When they are all done we can remove the flag. (Note how the code
ifdefed by the flag can be removed once we no longer need the old
way of doing things - that is, the new approach is simpler on the
binaryen side).
See #3043
|
| |
|
|
|
|
|
|
|
|
| |
This helps towards the goal of allowing emscripten to not always modify
the wasm during link. Until now wasm-emscripten-finalize always wrote
an output, while with this PR it only does so if it was asked to, either by
giving it an output filename, or asking for text output.
The only noticeable change from this should be to make what was an
error before (not specify an output or ask for text) into a non-error (run
and print metadata, but do not write the wasm).
|
| | |
|
| |
|
|
|
|
| |
The core logic is still living in EmscriptenGlueGenerator because
its used also by fixInvokeFunctionNames.
As a followup we can figure out how to make these more independent.
|
| |
|
|
|
| |
This new pass takes an optional stack-check-handler argument
which is the name of the function to call on stack overflow.
If no argument is passed then it just traps.
|
| |
|
|
| |
This should not be needed since in emscripten standalone mode we
always include a crt1.o that includes _start.
|
| |
|
|
| |
Doing it this way happens to re-order the __assign_got_entries
function in the module, but its otherwise NFC.
|
| |
|
| |
First step in making wasm-emscripten-finalize use more passes.
|
| |
|
|
|
|
|
|
|
| |
The plan is that for standlone mode we can function just like wasi-sdk
and call the correct main from crt1.c.
For non-standalone mode we still want to export can call main directly
so we rename __main_argc_argv back to main as part of finalize.
See https://reviews.llvm.org/D70700
|
| |
|
|
|
|
|
| |
These are now implemented in assembly as part of emscripten's
compiler-rt.
See: https://github.com/emscripten-core/emscripten/pull/11166
|
| |
|
|
|
| |
If wasm-emscripten-finalize is given the BigInt flag, then we will
be using BigInts on the JS side, and need no legalization at all
since i64s will just be BigInts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depends on emscripten-core/emscripten#10741
which ensures that table indexes are unique. With that guarantee,
a main module can just add its function pointers into the table, and
use them based on that index. The loader will then see them in the
table and then give other modules the identical function pointer for
a function, ensuring function pointer equality.
This avoids calling fp$ functions during startup for the main
module's own functions (which are slow). We do still call fp$s
of things we import from outside, as we don't have anything to
put in the table for them, we depend on the loader for that.
I suspect this can also be done with SIDE_MODULES, but did not
want to try too much at once.
|
| |
|
|
|
|
|
|
| |
(#2544)
Without this, the first wasm-opt invocation will remove it. But it
can be very large, and we will soon start to automatically do
updating on it when it exists, so avoid the work if we aren't
actually building a final output with dwarf.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optionally track the binary format code section offsets,
that is, when loading a binary, remember where each IR
node was read from. This is necessary for DWARF
debug info, as these are the offsets DWARF refers to.
(Note that eventually we may want to do something
else, like first read the DWARF and only then add
debug info annotations into the IR in a more LLVM-like
manner, but this is more straightforward and should be
enough to update debug lines and ranges).
This tracking adds noticeable overhead - every single
IR node adds an entry in a map - so avoid it unless
actually necessary. Specifically, if the user passes in
-g and there are actually DWARF sections in the
binary, and we are not about to remove those sections,
then we need it.
Print binary format code section offsets in text, when
printing with -g. This will help debug and test dwarf
support. It looks like
;; code offset: 0x7
as an annotation right before each node.
Also add support for -g in wasm-opt tests (unlike
a pass, it has just one - as a prefix).
Helps #2400
|
| |
|
|
|
|
|
|
|
| |
In normal mode we call a JS import, but we can't import from JS
in standalone mode. Instead, just trap in that case with an
unreachable. (The error reporting is not as good in this case, but
at least it catches all errors and halts, and the emitted wasm is
valid for standalone mode.)
Helps emscripten-core/emscripten#10019
|
| |
|
|
|
| |
Also fix, but in splitting the names of the trace channels. Obviously
I can't write string.split correctly in C first time around.
|
| |
|
|
|
|
| |
This means that debugging/tracing can now be enabled and controlled
centrally without managing and passing state around the codebase.
|
| |
|
|
|
|
| |
This will allow us to pass pass args to
wasm-emscripten-finalize, which runs
legalize-js-interface internally, which recently
added an optional argument.
|
| |
|
|
|
| |
(#2384)
In this mode crt1 takes care of calling it.
|
| | |
|
| |
|
| |
The flag indicates that we want to run the wasm by itself, without JS support. In that case we don't emit JS dynCalls etc., and we also emit a wasi _start if there is a main, i.e., we try to use the current conventions in the wasm-only space.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This is useful for front-ends which wish to selectively enable or
disable coloring.
Also expose these APIs from the C API.
|
| |
|
| |
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.
|
| |
|
| |
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
|
| |
|
|
|
| |
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.
|
| |
|
| |
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.
|
| |
|
| |
And run it in wasm-emscripten-finalize. This will prevent the emscripten output from changing when the target features section lands in LLVM.
|
| |
|
|
| |
We now implement addFunction by creating a wasm module to wrap
that JS function and simply adding it to the table.
|
| |
|
|
|
| |
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.
|
| |
|
| |
To calculate the metadata, we must look at the segments. If we split them out earlier (which we do for threads), they aren't there.
|
| |
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Even when we don't want to fully legalize code for JS, we should still legalize things that only JS cares about. In particular, dynCall_* methods are used from JS to call into the wasm table, and if they exist they are only for JS, so we should only legalize them.
The use case motivating this is that in dynamic linking you may want to disable legalization, so that wasm=>wasm module calls are fast even with i64s, but you do still need dynCalls to be legalized even in that case, otherwise an invoke with an i64 parameter would fail.
|
| | |
|
| | |
|
| |
|
| |
I broke this to be alwasy empty in #1795.
|
| |
|
|
|
|
|
|
| |
expected names (#1795)
This means lld can emscripten can disagree about the naming of these
imports and emscripten-wasm-finalize will take care of paper over the
differences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
