Error: "exports count of 143958 exceeds internal limit of 10000"

[anutosh491]

Hi,

I am facing this issue

RuntimeError: Aborted(CompileError: WebAssembly.instantiate(): exports count of 143958 exceeds internal limit of 100000 @+214486)

I am not planning on missing out any function/symbol (hence providing EXPORT_ALL=1 to em++ and --export-all to wasm-ld)

When building with EMCC_DEBUG=1 emmake make -j16 install VERBOSE=1, it generates a file (/var/folders/m1/cdn74f917994jd99d_2cpf440000gn/T/emscripten_temp/tmp6qr4um78.json) which is giving me more info on the exported functions. I see a lot of them hence wanted to confirm if this is due to the huge list of functions I am interested in and is there a way to get past this error ?

I've pasted the contents of the file here for anyone interested (https://raw.githubusercontent.com/anutosh491/xeus-cpp-lite-debug/refs/heads/main/tmp6qr4um78.json)

[anutosh491]

When i get rid of the --export-all flags I end up with this file (https://github.com/anutosh491/xeus-cpp-lite-debug/blob/main/tmptqjqh2js.json) but then I lose out of symbols which are all present in the above and I end up with these errors when I host target.js and target.wasm

wasm-ld: error: incr_module_2.wasm: undefined symbol: __clang_Interpreter_SetValueNoAlloc

[anutosh491]

I guess adding -s EXPORTED_FUNCTIONS=['_clang_Interpreter_SetValueNoAlloc'] would add all exported functions and shown in the above + _clang_Interpreter_SetValueNoAlloc ?

I could try that but I was interested in all of them cause I am not sure what sort of symbols I need and the ones I can skip !

[sbc100]

Yes, you almost certainly don't want to be passing --export-all to the linker. By the way, are you running wasm-ld directly? Is there some reason you are not using em++ as your linker?

In terms of exporting symbols, you should only export symbol that you intent to use directly from JS, i.e. that you want to call from the embedder. What are you trying to build here? Are you trying to just run clang? If so, than you don't need any exports other than the default main symbol.

[anutosh491]

What are you trying to build here?

The issues I have been opening lately (1, 2 which I think you self assigned and this one) are all towards the same goal that is to get xeus-cpp-lite (xeus-cpp + jupyter-lite) working

Xeus-cpp is a Jupyter kernel that allows us to run C++ code on a jupyter notebook. Jupyter-lite basically aids running jupyter kernels so that you can have something completely in browser.
So basically we can say that the bigger goal is to run clang-repl in the browser.

Basically there are 4 layers here and all of them should be compiled against emscripten

1. xeus-cpp (the kernel)
2. CppInterOp (a thin wrapper/helper) over clang-repl/cling
3. llvm (for clangInterpreter, lldWasm etc)

i) Now llvm has been compiled cleanly to I have access to libclangInterpreter.a
ii) I am trying to either get libclangCppInterOp.a or libclangCppInterOp.so
iii) For libclangCppInterOp.a (I did this as you suggested to fix the undefined symbols and I can successfully come up with libclangCppInterOp.a but then when I'm trying to generate xcpp.js and xcpp.wasm (simply having target_link_libraries (xeus-cpp PUBLIC clangCppInterOp foo bar) I get an lld crash as noted on 2)
iv) Generating libclangCppInterOp.so wasn't tough (inspired by this issue) and the linking step and generation etc went smoothly (no undefined symbols or anything atleast while building)

But I end up with this error xcpp.js:2931 wasm-ld: error: incr_module_2.wasm: undefined symbol: __clang_Interpreter_SetValueNoAlloc

The stack trace tells me that

1. We have clang-repl instantiated.
2. We can Parse stuff (Parse from ParseAndExecute works)
3. Maybe execution is an issue. (Execute function fails)

[anutosh491]

So the error is basically coming from here

Pasting the stack trace too for more info

So I am kinda trying to make sure where the error is

1. The llvm build looks good

 anutosh491@Anutoshs-MacBook-Air lib % nm -C libclangInterpreter.a --defined-only | grep __clang_Interpreter_SetValueNoAlloc
00005cf4 T __clang_Interpreter_SetValueNoAlloc

2. Having a shared build or a static build for CppInterOp, looking at the error I am guessing __clang_Interpreter_SetValueNoAlloc should be present in the WASM_EXPORTS when finally build xeus-cpp.

So i am not sure what might be going wrong. Hence I was just passing (-s EXPORT-ALL =1 and target_link_options(xcpp PUBLIC "-Wl,--export-all") while building xeus-cpp.

Also now that I don't see any undefined symbol during build time but I see the above undefined symbol during runtime. I am just curious if this has something to do with mangling. I can see that almost all stuff coming out of clangInterpreter is like _ZNXXX... but then the above symbol defined here and being used here is using extern "C"

[anutosh491]

By the way, are you running wasm-ld directly? Is there some reason you are not using em++ as your linker?

No, I am not running wasm-ld directly. I am running em++ itself. My final link.txt looks like this when I use both the export flags
/Users/anutosh491/micromamba/envs/xeus-cpp-wasm-build/lib/python3.13/site-packages/emsdk/upstream/emscripten/em++ -Wl,--export-all -O0 -g --bind -Wno-unused-command-line-argument -fexceptions -s MODULARIZE=1 -s EXPORT_NAME=createXeusModule -s EXPORT_ES6=0 -s USE_ES6_IMPORT_META=0 -s DEMANGLE_SUPPORT=0 -s ASSERTIONS=2 -s ALLOW_MEMORY_GROWTH=1 -s EXIT_RUNTIME=1 -s WASM=1 -s -s STACK_SIZE=64mb -s INITIAL_MEMORY=256mb -s WASM_BIGINT -s FORCE_FILESYSTEM -s MAIN_MODULE=1 -s EXPORT_ALL=1 @CMakeFiles/xcpp.dir/objects1.rsp -o xcpp.js @CMakeFiles/xcpp.dir/linkLibs.rsp

That being said I am seeing this.

1. If I don't have the -Wl,--export-all and only have the EXPORT_ALL=1 here... it make no difference. I end up with the undefined symbols error
2. But the other way round (including --export-all) I see that __clang_Interpreter_SetValueNoAlloc is present in the EXPORTED_FUNCTIONS and the WASM_EXPORTS section (in the tmp6qr4um78.json produced when i run with emcc_debug=1)

But when I try option 2) I end up getting the above error

[anutosh491]

That being said, I think it would be appropriate to close this issue.

After exporting the required symbol something like --export=__clang_Interpreter_SetValueNoAlloc I still see the same wasm-ld error .... so I guess it might not even an issue related to exporting symbols. The error still shows that it is coming out of scanRelocations

[anutosh491]

Although I have closed the issue, I am curious to know what might be giving us the error.

For example now i am running this on the code cell

extern "C" int printf(const char*,...);
auto r1 = printf("r=%d\n", 1+1);

so I get this error xcpp.js:2972 wasm-ld: error: incr_module_2.wasm: undefined symbol: printf

1. So the error comes out of here (place which reports the undefined symbol)
2. The place where the symbol is extracted is this
3. I see that there is something called reloc.type on which the operations are based so we need to figure out what this is for our case.
   Also something like file->getSymbols() which gives us the symbols, so we kinda need to understand how the file incr_module_2.wasm is created and what symbols does it carry.
   Actually even to start with something like this ... I haven't understood as to what creates incr_module_0.wasm OR incr_module_1.wasm if they are even created. Obviously the file creation is happening here

This doesn't look like a symbol not present issue.

[sbc100]

Looking at the code in https://github.com/llvm/llvm-project/blob/9f796159f28775b3f93d77e173c1fd3413c2e60e/clang/lib/Interpreter/Wasm.cpp#L74-L86 it doesn't link in any standard libraries so it not suprising that things like printf are not defined.

Do you what that clang/lib/Interpreter/Wasm.cpp is designed to do? It certainly doesn't looks like its designed to link general purpose programs because there is not libc or compiler-rt mentioned there.

[anutosh491]

Hey @sbc100

Thanks for the reply

it doesn't link in any standard libraries

Ahh yes that's something I missed totally.

Do you what that clang/lib/Interpreter/Wasm.cpp is designed to do?

Yes, so this is where it at all starts. So Wasm.cpp was introduced as an attempt to help running clang-repl in the browser. The approach can be found here (https://compiler-research.org/assets/presentations/Anubhab_Ghosh_wasm_clangrepl.pdf)

Wasm.cpp basically is a code based representation of the approach stated above. So Wasm.cpp basically does this (contents on the 1st slide are basically something we can do, 2nd slide is basically how wasm.cpp helps us)

[anutosh491]

Well so as the above approach goes we would be interested in how we do the linking. Your reply tells me that we might be interested in more flags .... not sure maybe some more flags for standard libraries as follows !

-whole-archive
-lstubs-debug
-lc-debug
-ldlmalloc-debug
-lcompiler_rt
-lc++
-lc++abi-debug
--no-whole-archive

Along with what we already have. Does that look like the way to go here ?

[sbc100]

If you want to make the code in https://github.com/llvm/llvm-project/blob/9f796159f28775b3f93d77e173c1fd3413c2e60e/clang/lib/Interpreter/Wasm.cpp#L74-L86 somehow compatible with emscripten linker, I think that would represent a lot of work.

You would basically have to duplicate all/most of the logic in the emscripten linker in that Wasm.cpp file. I would not recommend attempted that unless are ready to dive deep into all the internal details of emscripten and add a lot of code to Wasm.cpp.

BTW, if you were going to try to make this work I would suggest getting it all working first with the normal native/desktop version of clang (i.e. solve the problem of making /clang/lib/Interpreter/Wasm.cpp much smarter before trying to make it all run inside of wasm).

[sbc100]

To give you an idea of the complexity here is just a small subset of the logic in the emscripten linker for generating the link command:

emscripten/tools/building.py

Lines 133 to 293 in 4b3bace

	def lld_flags_for_executable(external_symbols):
	cmd = []
	if external_symbols:
	if settings.INCLUDE_FULL_LIBRARY:
	# When INCLUDE_FULL_LIBRARY is set try to export every possible
	# native dependency of a JS function.
	all_deps = set()
	for deps in external_symbols.values():
	for dep in deps:
	if dep not in all_deps:
	cmd.append('--export-if-defined=' + dep)
	all_deps.add(dep)
	stub = create_stub_object(external_symbols)
	cmd.append(stub)
	if not settings.ERROR_ON_UNDEFINED_SYMBOLS:
	cmd.append('--import-undefined')
	if settings.IMPORTED_MEMORY:
	cmd.append('--import-memory')
	if settings.SHARED_MEMORY:
	cmd.append('--shared-memory')
	# wasm-ld can strip debug info for us. this strips both the Names
	# section and DWARF, so we can only use it when we don't need any of
	# those things.
	if settings.DEBUG_LEVEL < 2 and (not settings.EMIT_SYMBOL_MAP and
	not settings.EMIT_NAME_SECTION and
	not settings.ASYNCIFY):
	cmd.append('--strip-debug')
	if settings.LINKABLE:
	cmd.append('--export-dynamic')
	if settings.LTO and not settings.EXIT_RUNTIME:
	# The WebAssembly backend can generate new references to `__cxa_atexit` at
	# LTO time. This `-u` flag forces the `__cxa_atexit` symbol to be
	# included at LTO time. For other such symbols we exclude them from LTO
	# and always build them as normal object files, but that would inhibit the
	# LowerGlobalDtors optimization which allows destructors to be completely
	# removed when __cxa_atexit is a no-op.
	cmd.append('-u__cxa_atexit')
	c_exports = [e for e in settings.EXPORTED_FUNCTIONS if is_c_symbol(e)]
	# Strip the leading underscores
	c_exports = [demangle_c_symbol_name(e) for e in c_exports]
	# Filter out symbols external/JS symbols
	c_exports = [e for e in c_exports if e not in external_symbols]
	c_exports += settings.REQUIRED_EXPORTS
	if settings.MAIN_MODULE:
	c_exports += side_module_external_deps(external_symbols)
	for export in c_exports:
	if settings.ERROR_ON_UNDEFINED_SYMBOLS:
	cmd.append('--export=' + export)
	else:
	cmd.append('--export-if-defined=' + export)
	for e in settings.EXPORT_IF_DEFINED:
	cmd.append('--export-if-defined=' + e)
	if settings.RELOCATABLE:
	cmd.append('--experimental-pic')
	cmd.append('--unresolved-symbols=import-dynamic')
	if not settings.WASM_BIGINT:
	# When we don't have WASM_BIGINT available, JS signature legalization
	# in binaryen will mutate the signatures of the imports/exports of our
	# shared libraries. Because of this we need to disabled signature
	# checking of shared library functions in this case.
	cmd.append('--no-shlib-sigcheck')
	if settings.SIDE_MODULE:
	cmd.append('-shared')
	else:
	cmd.append('-pie')
	if not settings.LINKABLE:
	cmd.append('--no-export-dynamic')
	else:
	cmd.append('--export-table')
	if settings.ALLOW_TABLE_GROWTH:
	cmd.append('--growable-table')
	if not settings.SIDE_MODULE:
	cmd += ['-z', 'stack-size=%s' % settings.STACK_SIZE]
	if settings.ALLOW_MEMORY_GROWTH:
	cmd += ['--max-memory=%d' % settings.MAXIMUM_MEMORY]
	else:
	cmd += ['--no-growable-memory']
	if settings.INITIAL_HEAP != -1:
	cmd += ['--initial-heap=%d' % settings.INITIAL_HEAP]
	if settings.INITIAL_MEMORY != -1:
	cmd += ['--initial-memory=%d' % settings.INITIAL_MEMORY]
	if settings.STANDALONE_WASM:
	# when settings.EXPECT_MAIN is set we fall back to wasm-ld default of _start
	if not settings.EXPECT_MAIN:
	cmd += ['--entry=_initialize']
	else:
	if settings.PROXY_TO_PTHREAD:
	cmd += ['--entry=_emscripten_proxy_main']
	else:
	# TODO(sbc): Avoid passing --no-entry when we know we have an entry point.
	# For now we need to do this since the entry point can be either `main` or
	# `__main_argv_argc`, but we should address that by using a single `_start`
	# function like we do in STANDALONE_WASM mode.
	cmd += ['--no-entry']
	if settings.STACK_FIRST:
	cmd.append('--stack-first')
	if not settings.RELOCATABLE:
	cmd.append('--table-base=%s' % settings.TABLE_BASE)
	if not settings.STACK_FIRST:
	cmd.append('--global-base=%s' % settings.GLOBAL_BASE)
	return cmd
	def link_lld(args, target, external_symbols=None):
	if not os.path.exists(WASM_LD):
	exit_with_error('linker binary not found in LLVM directory: %s', WASM_LD)
	# runs lld to link things.
	# lld doesn't currently support --start-group/--end-group since the
	# semantics are more like the windows linker where there is no need for
	# grouping.
	args = [a for a in args if a not in ('--start-group', '--end-group')]
	# Emscripten currently expects linkable output (SIDE_MODULE/MAIN_MODULE) to
	# include all archive contents.
	if settings.LINKABLE:
	args.insert(0, '--whole-archive')
	args.append('--no-whole-archive')
	if settings.STRICT and '--no-fatal-warnings' not in args:
	args.append('--fatal-warnings')
	if any(a in args for a in ('--strip-all', '-s')):
	# Tell wasm-ld to always generate a target_features section even if --strip-all/-s
	# is passed.
	args.append('--keep-section=target_features')
	cmd = [WASM_LD, '-o', target] + args
	for a in llvm_backend_args():
	cmd += ['-mllvm', a]
	if settings.WASM_EXCEPTIONS:
	cmd += ['-mllvm', '-wasm-enable-eh']
	if settings.WASM_EXCEPTIONS or settings.SUPPORT_LONGJMP == 'wasm':
	cmd += ['-mllvm', '-exception-model=wasm']
	if settings.MEMORY64:
	cmd.append('-mwasm64')
	# For relocatable output (generating an object file) we don't pass any of the
	# normal linker flags that are used when building and executable
	if '--relocatable' not in args and '-r' not in args:
	cmd += lld_flags_for_executable(external_symbols)
	cmd = get_command_with_possible_response_file(cmd)
	check_call(cmd)

[anutosh491]

BTW, if you were going to try to make this work I would suggest getting it all working first with the normal native/desktop version of clang (i.e. solve the problem of making /clang/lib/Interpreter/Wasm.cpp much smarter before trying to make it all run inside of wasm).

Few comments here

1. I see that Wasm.cpp only comes into play when building clang (or rather clangInterpreter) against emscripten. (https://github.com/llvm/llvm-project/blob/ae509a085836079585228aede8a5017ad80e1aa9/clang/lib/Interpreter/Interpreter.cpp#L18-L20)
2. Also the discussion here([clang-repl] Support wasm execution llvm/llvm-project#86402) tells me that there might not be straightforward ways inside llvm just as of now to test this out through a bot. So I am guessing it is only through downstream projects like xeus-cpp/CppInterOp that we can test this out.

That being said, would this approach make sense

1. We run the script you showed above at the xeus-cpp layer, select the options and put them through an env variable and trickle it down to the wasm.cpp linker command