User Details
- User Since
- Sep 16 2016, 10:22 AM (340 w, 6 d)
Today
- a test
- feedback
Yesterday
- comments
The reason __attribute__((export_name("foo"))) doesn't work in all use cases is that we have a lot of existing code that uses the EMSCRIPTEN_KEEPALIVE macro. We also have run into other folks who want to include this is some kind of FOO_API, or EXPORT_API type macros. Its not possible to have such a macro map to the existing export_name since they don't include the symbol name: e.g:
Thu, Mar 23
I just figured out that this cannot replace the current use of __attribute__((used)) in emscripten because function attributes only work for functions and we need this mechanism to work for global data addresses too. There is simply no way to do something like Fn->addFnAttr("wasm-exported"); for a GlobalValue that isn't a function (as far as I can tell).
- limit to emscripten
I've limited to new attribute to only the emcripten triple.
- update test
- rebase
Any objections to landing this?
Tue, Mar 21
Tue, Mar 14
Mon, Mar 13
- feedback
- remove unused method
- error -> assert
WDYT Dan? My guess is that wasi-sdk doesn't currently need to express these reverse dependencies, so its not currently relevant.
Thu, Mar 9
Wed, Mar 8
- stub libraries
What you say ", TLS + dynamic linking will not work at the moment." do you mean just the debug info won't work? Or it won't work at all?
Tue, Mar 7
Mon, Mar 6
- rebase
- feedback
Feedback
- feedback
- Revert part
- revert ELF
In general, when making these kind of generic changes, would it be possible to also include wasm-ld (lld/wasm) so that we keep things as in-sync as possible?
Sat, Mar 4
Fixes
- dead code
- typos
Wed, Mar 1
lgtm % some minor nits
Feb 27 2023
- feedback
ptal
Feb 24 2023
Feb 13 2023
Feb 10 2023
Working on adding a test now. This is needed to run wasm64 + pthread + dynamic linking tests on the emscripten side.
Jan 31 2023
Jan 27 2023
Jan 17 2023
Jan 10 2023
Jan 9 2023
I think this change is find to land as is. If we decided to simplify that .s format we can possibly simplify the parser code later.
I wonder if its too late to change the requirement such that .functype should always come before the label? This would make the code simpler and the assembly format more consistent maybe?