- User Since
- Nov 12 2013, 11:44 AM (291 w, 6 d)
Sat, Jun 8
Wed, Jun 5
The PIC portion of this patch is now split off as r362638. This patch now just contains the __attribute__((used))/no_dead_strip changes.
The wasi-libc PR is here.
Mon, Jun 3
- Rename IMPLICITLY_USED to NO_STRIP
- Rename IMPLICITLY_USED to NO_STRIP.
- Remove isExported and setExported accessors.
Fri, May 31
Cool, this is nicer than my version :-).
Tue, May 28
This patch now depends on a corresponding LLVM patch: https://reviews.llvm.org/D62542
Mon, May 27
Fri, May 24
If I follow the discussion correctly, there are subtle ABI issues either way, so making fence a RMW now doesn't give us fully a future-proof ABI anyway. Consequently, I would prefer to make this patch conditional on the Emscripten triple, as wasm32-wasi and wasm32-unknown-unknown don't require Emscripten compatibility.
Tue, May 21
A function like this might be implemented in compiler_rt/libgcc or libc, which might in make future WASI system calls or future wasm language features underneath. An interface like __wasm_return_address doesn't commit to a particular implementation. I'm not suggesting enabling it for other targets now, just asking if it makes sense to pick a name which isn't tied to Emscripten.
Would it make sense to take this opportunity to rename the library function, from emscripten_return_address to something more general, like __wasm_return_address or __wasm_callsite_identifier or something, so that non-Emscripten environments could implement it too if they wished?
Mon, May 20
I don't know the lld internals well, but the basic approach here sounds right.
May 2 2019
If "$sysroot/lib" ends up coming to mean "wasm32" because people come to depend on that, then wasm64 may end up needing to be different in a gratuitous way, which I'd like to avoid.
The value of supporting single-arch sysroots is unclear to me. It's always possible to have a sysroot with libraries for just one architecture installed, even with multi-arch paths. Is this just about compatibility with build scripts and tools which are hard-coded to "$sysroot/lib"?
If libraries don't correctly install into multi-arch directories, can we fix the libraries? We do this in the wasi-sdk repo to fix up the libc++ and libc++abi libraries, for example.
May 1 2019
Apr 30 2019
Drop the getentropy header file change from this patch.
Fixed in r359605.
- Convert the test input to yaml.
- Add ObjectYAML support for EXPLICIT_NAME symbols too.
Apr 29 2019
Implemented proper diagnostics for import_name/import_module on functions with definitions, and updated the test.
I made the error message include the name of the function, and added a test.
Apr 24 2019
Apr 22 2019
The theory here is that br_table represents the performance characteristics of a jump table, while br_if represents the performance characteristics of a branch. In hardware, a small switch with 3 cases is often more efficient with a couple of conditional branches than a jump table.
Apr 16 2019
Mar 19 2019
Mar 18 2019
Mar 14 2019
In the future, atomics will likely be enabled by default, however it will continue to be desirable to be able to select non-shared memory, since non-shared memory doesn't require a maximum size, and since it can make interoperating with JS and other external code simpler. Is it possible to structure this patch in a way that supports this?
Feb 28 2019
I've now made an updated post on https://github.com/WebAssembly/tool-conventions/issues/59.
Wasm gives users reasons to want -mthread-model single that other architectures don't, even when -matomics is enabled by default.
Feb 27 2019
This is still a little confusing to me. -matomic is supposed to be a subtarget flag, stating that the wasm implementation we will run on supports atomic instructions. -mthread-model posix is about the C++ interpretation -- what style implementation of memory model do we want? In the future, -matomic may become enabled by default, when enough wasm engines generally support it. However, -mthread-model single/posix may still be useful to control independently, because even with wasm engines supporting atomic, there are reasons users might still want to compile their apps single-threaded: access to linear memory with no declared max, lower overall code size, or other things.
Feb 25 2019
Feb 7 2019
- -matomics means -mthread-model posix
That sounds reasonable to me too.
- Add MC/WebAssembly and lld tests
- Set the WASM_SYMBOL_NAME_EXPLICIT flag when a symbols name differs from its import name.
Feb 5 2019
Feb 4 2019
- Rename printf_no_Lf to __small_printf.
- Add more tests.
- Split out enabling the iprintf optimization for WASI, to be submitted in a separate patch later.
- Use a symbol flag to indicate when a custom symbol name is present.
- Revert the version number bump.
- Allow globals and events to have custom symbol names too, for consistency.
Feb 1 2019
I think WebAssembly is in the same situation as most other architectures, as discussed here:
Jan 28 2019
- Remove the target constraint, allowing the main rewrite logic to work on all wasm32 targets.
- Remove the now-unneeded "wasm-temporary-workarounds" flag altogether.
- This uncovered some bugs with wrappers for main when main is only a declaration; fix those as well.
Jan 24 2019
Jan 14 2019
Sorry for the delay here. Yes, let's land this.