Module.instantiateWasm is a callback the user provides, and then the user is
in change of fetching and instantiating the wasm. In that code path emscripten
never sees the wasm binary, which means we cannot create a
WasmOffsetConverter.
With this PR we will not hang on startup, and we will still detect problems, but
the sanitizer's own stack traces will mark function names as "unknown". That will
limit the santizer's usefulness, but they do still detect errors, and the browser's
own stack traces may be enough to diagnose things.
Fixes#13424
Fix incorrect "function in Table but not functionsInTableMap" assertions
by adding new entries in the table from a side module to
functionsInTableMap.
Fixes#13347Fixes#13040
* Add support for emmalloc for 4GB heap sizes. Fix an issue that caused -s MAXIMUM_MEMORY=4G -s ABORTING_MALLOC=0 to crash, instead of returning zero on failed growth operation. Remove the unnecessary 16MB minimum heap growth size clamp: heap growth is not that costly, and 16MB can be excessive for tiny applications. Add emmalloc-debug and emmalloc-debug-log MALLOC options that allow building emmalloc with its debugging options, without needing to manually edit emmalloc.cpp sources to activate. Remove old asm.js/32-bit only code in emmalloc. Remove old workaround for wasm2js codegen bug in emmalloc.
* Update embuilder.py.
* Rename emmalloc special targets to "memvalidate" and "verbose", and adjust their variations to fix embuilder.py.
* Update tests.
* Update variations.
* Fix emmalloc system lib naming.
* Fix memory region merging check and test_emmalloc naming.
* Address review
* Fix case on test_zzz_zzz_4gb_fail
* Rebaseline code size tests
This enables certain parallel phases such as running llvm-nm in parallel
when calculating system libraries to link. Developers who what to
disable even that can continue to use `EMCC_CORES=1`.
Continue to disable parallelism in debug mode in these two cases:
1. When building system libraries/ports at link time.
2. In the test runner
While the risk using parallelism and debug mode is diminished due to
recent changes (#13329#13370) it is still possible for emscripten
processed in debug mode to interfere with each other due to sharing
a temp directory.
See https://bugs.chromium.org/p/chromium/issues/detail?id=1171844
We never really supported this syscall but prior to #13272 this
fact was not evident since the generic socketcall handler had a
catchall the returned ENOSYS.
Fixes: #13393
These instructions were removed from the spec proposal and from V8 because they
were redundant with i8x16.any_true, which has identical semantics. Since they
were removed from V8, these tests started failing. This PR fixes the breakage by
removing the obsolete tests. See https://github.com/WebAssembly/simd/issues/416.
* WebGPU: Add support for new binding layout model
* WebGPU: Update color to use doubles
* WebGPU: Update generator URL from master to main in struct_info.json
* Rebaseline reference_struct_info.json
Co-authored-by: Kai Ninomiya <kainino@chromium.org>
These improvements to the `FROZE_CACHE` setting allow for a
pre-populated, read-only cache. In this scenario the cache
is cannot ever be locked, and that we don't even write
the sanity file.
Users can still force a sanity check with `emcc --check`
but no sanity file will ever be written.
Fixes: #13369
Enables loadWebAssemblyModule to use both compiled wasm and binary.
expose mergelibSymbols so it can be used postInstantiate.
For performance reasons we fetch and compile a side module on a separate
thread and post it over to the worker thread with the main module.
Fixes: #13262
Under UBSan, comparing type_infos triggers a lookup in UBSan's typeinfo cache.
When this cache is not warm, this causes a cache miss, and the code path that
handles that ends up calling __dynamic_cast. __dynamic_cast itself ends up
comparing type_infos and this recursion ends up exhausting the stack.
```
RangeError: Maximum call stack size exceeded
...
at std::type_info::operator==(std::type_info const&) const
at is_equal(std::type_info const*, std::type_info const*, bool)
at __dynamic_cast (<anonymous>:wasm-function[40]:0x8fb)
at __ubsan::checkDynamicType(void*, void*, unsigned long)
at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
unsigned long, unsigned long, __ubsan::ReportOptions)
at __ubsan_handle_dynamic_type_cache_miss
at std::type_info::operator==(std::type_info const&) const
...
```
This is not a problem on native platforms because inlining and follow-on
optimizations remove the call to type_info::operator== under __dynamic_cast, so
UBSan never re-enters its type checking routine. In Emscripten, however, we
build libc++abi with -Oz, so these optimizations do not take place. The fix is
to add __attribute__((always_inline)) to type_info::operator==, which is enough
to get the recursion optimized out in -Oz.
Fixes#13330.
Fixes#13324.
Since we don't have many users who use RELOCATABLE directly it
went unnoticed that setting this option on its own was causing all
symbols to be included and exported.
Fixes#13029
This extra argument (include_internal) and the extra complexity
it entailed had only a single call site in the test suite.
Calling llvm-nm directly in the test suite is much simpler.
When using pthread with more than one dynamic library the order in which the libraries are linked when the module is loaded in the browser's main thread is non deterministic. This makes the function pointers between the main thread and the workers not compatible.
With this change the main thread links the dynamic libraries in the same deterministic order as in the workers.
This fix only applies to libraries linked when the module is loaded and adds a test to lock down this behavior.
Libraries linked only through dlopen remains unsupported.
Fix#13303
* Restore the dynCall() and dynCall_sig() API into the build when -s USE_LEGACY_DYNCALLS=1 is passed. Add support for dynCall() in MINIMAL_RUNTIME builds (that was not implemented before).
* Add ChangeLog entry.
* Rename USE_LEGACY_DYNCALLS to DYNCALLS.
* Inline getDynCaller.
* Address review.
* Merge new dynCall test with old.
* Reformat parseTools.js
* Add HarfBuzz flag to SDL2_ttf rev 703ebc7c66fd.
`TTF_USE_HARFBUZ` flag adds complex script support
to SDL_ttf, hence the update to the latest revesion.
Fixes#12845.
* Add a new test for Arabic shaping with HarfBuzz.
This commit adds a test which uses SDL2_ttf for Arabic Shaping with
HarfBuzz. In order to do so, a font with Arabic Glyphs was necessary.
Therefore NotoNaskhArabic font was added.
test_pthread_cond_signal_1_1 has very tight timing requirements, and
expects that side threads will be woken and do some action in very short
time. This causes occasional spurious fail of this test not because side
thread(s) hasn't been woken by pthread_cond_signal, but because this
threads hasn't been scheduled and hasn't get CPU on time.
See #13283
Without this check there is a race to create that sanity file when
emscripten if first used. I noticed this strange behavior when I would
run the test suite just after clearig the cache.
On my machine the test suite would launch many emcc processes and each
of them would notice the sanity file as missing and run the checks.
Some of them would see an empty sanify file that one of the other
processes was in the middle of creating (before they flushed it), and
when this happens that process would try to clear the cache! This
resulted in the cache being clearing by one process while it was being
populated by another. Not good.
The fix is the hold the cache lock while we check for the sanity file
and while we run the sanity checks.
This problem has always existed but was recently exacerbated by the fact
that we populate the sysroot headers as soon as we start emcc.
Also remove superfluous ensure() calls. Since we call this during
the constructor these days the cache can be assumed to always exist.
Remove the optimization (again) for the special case of single object
input, which skips the linker and directly copies the input object file
to output.
This behavior interferes with linking (merging) all objects in a
library archive into a single object, done with the following command:
cc -o lib.o -r -Wl,--whole-archive lib.a
The optimization was once useful when no clear distinction was made
between compile mode and link-only mode. It was also required for
compatibility (see #9510 and #9571).
However, #9510 was addressed by #9511, and #9600 introduced the '-r'
flag that allows to explicitly indicate linking to an object, making the
optimization less useful.
Although not strictly defined by POSIX, it is done by most (all?)
other implementations, most often in patches over the years as
places got forgotten.
This is mostly useful to allow quick comparing between sockaddr_in
to see if they are the same address.
Fixes#12998
As part of the pending musl update we can no longer (or at least it
becomes problematic) to compile internal musl headers alongside the
public headers. To avoid this, this change updates gen_struct_info.py
to compile internal headers separately.
To facilitate this, this change adds support for compiling groups of
headers and merging the results into a single json output.
As part of debugging this I added support for compiling every header
file in isolation. While this is slow, it uncovered a couple of
issues where structs and defines that were listed under the wrong
header and also a header that could not be compiled on its own
(SDL_pixels.h).
This fixes big where linking MAIN_MODULE and libgl was bring in
undefined references to GL2 symbols. Normally including this extra
`webgl.c` file in the library would be harmless since it will be ignored
if no GL2 symbols are used.
However, with MAIN_MODULE mode all objects from all libraries are
included which means that webgl2.o is included which itself references
all webgl2 symbols.
The problem specifically is that `webgl2.c` includes
`emscripten_webgl2_get_proc_address` which in turn references all
the `emscripten_XXX` versions of the GL2 API such as
`emscripten_glReadBuffer` which are defined in `library_webgl2.js`
Fixes: #13101
* In PR #7918, the option MEMFS_APPEND_TO_TYPED_ARRAYS=0 was removed, dropping the support for using regular JS Arrays to back MEMFS file storage. In this PR, complete the removal of old code that related to JS Array backing, since all files are now typed array backed.
* Migrate tests to use the MEMFS typed array API.
* Fix tests.
This support is still experimental and has some major
caveats:
- Only supports load-time dynamic linking
- No support for sharing TLS data between dylibs.
The major change is that workers now also call the module `run` function
although they exit early, once dynamic libraries have all been loaded.
See: #3494
- Properly read from the circular buffer (fixes#13173)
- Fix requested frame count check (it was failing when requested frequency was higher than source frequency)
Dexter Chua
Sam Clegg
Alon Zakai
jprendes
juj
Derek Schuff
Thomas Lively
Hugo Amnov
waterlike86
mehdisadeghi
Adam Bujalski
iamahuman
Patric Stout
Raffarti
Kagami Sascha Rosylight