Skip to content

Conversation

@sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Dec 20, 2019

This matches the current behavior of fastcomp since #7371 disabled
EXPORT_ALL for MAIN/SIDE_MODULEs.

Since most of our dylink tests set EXPORT_ALL this didn't get noticed.

This matches the current behavior of fastcomp since #7371 disabled
EXPORT_ALL for MAIN/SIDE_MODULEs.

Since most of our dylink tests set EXPORT_ALL this didn't get noticed.
@sbc100 sbc100 force-pushed the match_export_all_behaviour_with_fastcomp branch from 2ac6d02 to 1bf0514 Compare December 20, 2019 03:14
Copy link
Member

@kripken kripken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is maybe not the way to go. My understanding of EXPORT_ALL is that it exports stuff onto the Module object, and nothing more. It has no effect on keeping code alive through compiling and linking, in particular.

(It is true that it also affects metadce, which is arguably odd, but that's a special optimization after normal compilation and linking, so it's debatable; perhaps we should remove that.)

So I don't think EXPORT_ALL should be used when interfacing with LLVM, clang, wasm-ld, etc. It should just affect exporting JS stuff onto Module.

@sbc100 sbc100 closed this Jan 9, 2020
@sbc100 sbc100 deleted the match_export_all_behaviour_with_fastcomp branch January 9, 2020 02:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants