- User Since
- Nov 12 2013, 11:44 AM (301 w, 27 m)
Tue, Aug 13
I have a slight preference for landing this change too.
Mon, Aug 12
x86 uses address spaces starting at 256 and counting up for its architecture-specific address spaces. The docs say "Address spaces 1-255 are currently reserved for user-defined code." so we should consider using 256 here.
Jul 19 2019
This allows for us to fall back from arch-specific to generic headers as needed. The same can be true of libraries. Not all libraries contains compiled code. .so files can also be linker scripts that reference other libraries in which case they can be arch-neutral.
My opinion isn't too strong here either. wasm32 doesn't need 8 bytes for this, and there's an existing ABI knob to use less, so it seems to make sense to use it.
Jul 18 2019
Jul 10 2019
This looks nice!
Jul 8 2019
The actual compiler crash here came from the fact that we don't have an entry for llvm.clear_cache in the builtin function signature table. Suppose we added a signature for it. Then, we'd get LLVM's and compiler-rt's default behavior, which would be to call __clear_cache, and ultimately just abort at runtime.
Any code that thinks it needs to "clear the cache" is very likely doing something which won't actually work on wasm. Would it be reasonable to issue a report_fatal_error here?
Jun 16 2019
Jun 8 2019
Jun 5 2019
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.
Jun 3 2019
- Rename IMPLICITLY_USED to NO_STRIP
- Rename IMPLICITLY_USED to NO_STRIP.
- Remove isExported and setExported accessors.
May 31 2019
Cool, this is nicer than my version :-).
May 28 2019
This patch now depends on a corresponding LLVM patch: https://reviews.llvm.org/D62542
May 27 2019
May 24 2019
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.
May 21 2019
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?
May 20 2019
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.