-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Allow JS library dependencies to be added in source code. #17854
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
c1da048
to
6221d6d
Compare
I guess we should try to make a more generic version of this that would satisfy #14729 fully? |
Depends on this llvm change: https://reviews.llvm.org/D133884 |
fb5309f
to
9ba7172
Compare
Depends on WebAssembly/binaryen#5109 to avoid minor codesize regressions. |
0282262
to
3c6126c
Compare
To make it more generic and potentially useable for marking methods async (or any extra attributes we want). What about introducing a function attribute annotation that is preserved and extractable in metadata.
Then we could have
|
That looks like an awesome idea. I don't think that |
Clang supports annotate (it generates IR for it), but yeah we'd have to pipe it all the way through and then remove it like the em_js stuff. This is the page I saw about it awhile ago when I was looking into some bindings options. |
That certainly sounds like a great long term plan but needs a fair amount of work in llvm and wasm-ld to pipe those though I think. I still think it would be reasonable to land this change which can be used in the interim. WDYT? I guess the downside is it might need to keep this mechanism alive even after the new one arrives. (Actually maybe that isn't true.. I think we can define EM_JS_DEPS in terms of your proposed EM_DEPS?) |
Landing this in mean time sounds good. I saw you were doing some LLVM work, so I thought maybe it wouldn't be much more to do the annotation part (I have no idea). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
* | ||
* Dependencies declared in this way will be included if-and-only-if the object | ||
* file (translation unit) in which they exist is included by the linker, so | ||
* it makes sense co-locate them with the EM_JS or EM_ASM code they correspond |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* it makes sense co-locate them with the EM_JS or EM_ASM code they correspond | |
* it makes sense to co-locate them with the EM_JS or EM_ASM code they correspond |
|
||
/* | ||
* EM_JS_DEPS: Use this macro to declare indirect dependencies on JS symbols. | ||
* The first argument is just unique name for the set of dependencies. The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* The first argument is just unique name for the set of dependencies. The | |
* The first argument is just a unique name for the set of dependencies. The |
This looks good. I wonder if this could be expanded to also cover JS library functions -> C functions dependencies? |
I would love to find a way to do that yes. Such dependencies have to be present and wasm-ld time though. i.e. wasm-ld has to resolve them while its linking, not output them. It would be some kind of pattern like this:
One way to do that is to create some kind of dummy shared library or object file for each JS library, before running the linker. But I think this dummy object would probably have to be in a format that currently doesn't exist. It would be more like a linker script. I very much like this idea, but it needs fleshing out. |
This change introduces a new EM_JS_DEPS macros that can be used to specific the JS library dependencies of user code in EM_JS and/or EM_ASM blocks. This is especially important for library authors who don't want to have their users maintain link-time list of required symbols. See #14729
This should probably be documented somwhere other than just the release notes, presumably in https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html ? |
This change introduces a new EM_JS_DEPS macros that can be used to specific the JS library dependencies of user code in EM_JS and/or EM_ASM blocks.
This is especially important for library authors who don't want to have their users maintain link-time list of required symbols.
See #14729