Skip to content

Conversation

anutosh491
Copy link
Member

When running clang-repl in the browser we end up having something like the following
"" -cc1 -triple wasm32-unknown-emscripten ...... -main-file-name "<<< inputs >>>" .... -fvisibility=hidden .... -o "<<< inputs >>>.o" -x c++ "<<< inputs >>>"

Due to the default introduced through this commit (e3d71e1#diff-b5496baaf5c83e1ffa1a26d0815843b8d3224aba84366cbb6aeecf703808c803R2083)

That being said, when we generated the shared libraries to be loaded on top of the main module while running clang-repl in the browser, we have to surpass the above through --export-all

This is because obviously incr_module_XX.wasm might want to access symbols out of file from incr_module_XX-1.wasm to incr_mdoule_0.wasm

But this also exports some problematic things like __dso_handle that causes conflicts across modules.

image

A better way to deal with this is to pass -fvisibility=default to the CompilerInstance.

@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Nov 19, 2024
@llvmbot
Copy link
Member

llvmbot commented Nov 19, 2024

@llvm/pr-subscribers-clang

Author: Anutosh Bhat (anutosh491)

Changes

When running clang-repl in the browser we end up having something like the following
"" -cc1 -triple wasm32-unknown-emscripten ...... -main-file-name "&lt;&lt;&lt; inputs &gt;&gt;&gt;" .... -fvisibility=hidden .... -o "&lt;&lt;&lt; inputs &gt;&gt;&gt;.o" -x c++ "&lt;&lt;&lt; inputs &gt;&gt;&gt;"

Due to the default introduced through this commit (e3d71e1#diff-b5496baaf5c83e1ffa1a26d0815843b8d3224aba84366cbb6aeecf703808c803R2083)

That being said, when we generated the shared libraries to be loaded on top of the main module while running clang-repl in the browser, we have to surpass the above through --export-all

This is because obviously incr_module_XX.wasm might want to access symbols out of file from incr_module_XX-1.wasm to incr_mdoule_0.wasm

But this also exports some problematic things like __dso_handle that causes conflicts across modules.

image

A better way to deal with this is to pass -fvisibility=default to the CompilerInstance.


Full diff: https://github.com/llvm/llvm-project/pull/116779.diff

2 Files Affected:

  • (modified) clang/lib/Interpreter/Interpreter.cpp (+1)
  • (modified) clang/lib/Interpreter/Wasm.cpp (-1)
diff --git a/clang/lib/Interpreter/Interpreter.cpp b/clang/lib/Interpreter/Interpreter.cpp
index 73ad766e655180..999271aae7491d 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -197,6 +197,7 @@ IncrementalCompilerBuilder::CreateCpp() {
   Argv.push_back("-target");
   Argv.push_back("wasm32-unknown-emscripten");
   Argv.push_back("-shared");
+  Argv.push_back("-fvisibility=default")
 #endif
   Argv.insert(Argv.end(), UserArgs.begin(), UserArgs.end());
 
diff --git a/clang/lib/Interpreter/Wasm.cpp b/clang/lib/Interpreter/Wasm.cpp
index 79efbaa03982d0..6d4cc478dd6a85 100644
--- a/clang/lib/Interpreter/Wasm.cpp
+++ b/clang/lib/Interpreter/Wasm.cpp
@@ -75,7 +75,6 @@ llvm::Error WasmIncrementalExecutor::addModule(PartialTranslationUnit &PTU) {
                                           "-shared",
                                           "--import-memory",
                                           "--no-entry",
-                                          "--export-all",
                                           "--experimental-pic",
                                           "--stack-first",
                                           "--allow-undefined",

Copy link

github-actions bot commented Nov 19, 2024

✅ With the latest revision this PR passed the C/C++ code formatter.

@anutosh491
Copy link
Member Author

I just realized that cleanUp shouldn't use const. While building against emscripten, I go this error

 │ │ /home/runner/work/recipes/recipes/output/bld/rattler-build_llvm_1732028457/work/clang/lib/Interpreter/Wasm.cpp:111:38: error: out-of-line definition of 'cl
 │ │ eanUp' does not match any declaration in 'clang::WasmIncrementalExecutor'
 │ │   111 | llvm::Error WasmIncrementalExecutor::cleanUp() const {
 │ │       |                                      ^~~~~~~
 │ │ /home/runner/work/recipes/recipes/output/bld/rattler-build_llvm_1732028457/work/clang/lib/Interpreter/Wasm.h:31:15: note: member declaration does not match
 │ │  because it is not const qualified
 │ │    31 |   llvm::Error cleanUp() override;
 │ │       |               ^         ~~~~~~~~

Fixed this through the latest commit.

@anutosh491
Copy link
Member Author

anutosh491 commented Nov 28, 2024

Closing as superseded by #117978

@anutosh491 anutosh491 closed this Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema" clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants