- User Since
- Nov 12 2013, 11:44 AM (333 w, 2 h)
Cool, LGTM, with optional suggestion for signed char below:
Fri, Mar 27
Very cool, thanks for putting this together!
Thu, Mar 26
Instead of creating a new LLVM-IR-level attribute here, could you have clang translate the attribute to "wasm-export-name", to keep the LLVM-IR level simpler?
Wed, Mar 18
The commit description says "not ordered to group destructors with common associated objects" but it looks this patch is doing grouping by associated object. Is that intentional?
- Add a comment.
- Add a test of two destructors with different priorities and the same associated object.
Feb 19 2020
Looks good, with the clang-format lint fixed :-).
Jan 15 2020
@sbc100 Friendly ping :-).
Jan 13 2020
Dec 21 2019
Address review feedback.
I apologize for the extraordinary delays here; at long last, I've now addressed your feedback.
Dec 20 2019
To support a transition to the new system, temporarily define a __main_void alias for no-argument main. This allows libc to detect whether it's calling old-style or new-style main and do the right thing.
Dec 17 2019
This updates the main vs __main_argc_argv patch so that it doesn't apply to Emscripten targets, following the discussion in https://github.com/WebAssembly/tool-conventions/pull/134.
Dec 16 2019
Nov 27 2019
Nov 26 2019
I've done some more experimenting with this, and it turns out not to work very well, because calls to these functions get generated after LTO runs, so I'll abandon this.
Nov 25 2019
I've now posted https://reviews.llvm.org/D70677 which should fix the test failure when LLVM_APPEND_VC_REV=NO is set.
Nov 21 2019
Nov 20 2019
Do you think that setting this attribute should also prevent GC?
It appears this doesn't handle exporting an imported function yet, which is fine for now, but it would be good to issue a warning, because wasm itself is capable of representing this:
void aaa(void) __attribute__((import_module("imp"), import_name("foo"), export_name("bar")));
Don't run wasm-opt with -O0.
Use PATH instead of WASM_OPT to find wasm-opt.
Sep 21 2019
This kind of thing ought to have helped code like
extern int A;
Sep 18 2019
Would it be better to do this check in LLVM, in the backend, with a report_fatal_error?
Aug 30 2019
Aug 29 2019
- Use -wasm-disable-explicit-locals -wasm-keep-registers to make the test more readable
Include the basic test case.
Abandoning in favor of https://reviews.llvm.org/D66968.
https://reviews.llvm.org/D66968 is now a patch implementing the lld side of this.
"memory" is now a de-facto standard. We may still be able to change it, but we'll now need a transition plan.
Aug 13 2019
I have a slight preference for landing this change too.
Aug 12 2019
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.