__embind_initialize_bindings is stripped from export table in Release + pthreads build

[laminowany]

This is a regression in 3.1.70, on previously tested version 3.1.56 it worked correctly. My application gets undefined reference to __embind_initialize_bindings during runtime.

There is a code which adds __embind_initialize_bindings to exported symbols:

emscripten/tools/link.py

Lines 508 to 509 in 119a427

	if settings.EMBIND:
	settings.REQUIRED_EXPORTS.append('_embind_initialize_bindings')

but this seems to be stripped during call to binaryen:

emscripten/tools/building.py

Lines 842 to 847 in 119a427

	out = run_binaryen_command('wasm-metadce',
	wasm_file,
	wasm_file,
	args,
	debug=debug_info,
	stdout=PIPE)

The binaryen takes an DCEGraph as an input, and when I inspect the json of graph it has following entry:

{
    "name": "emcc$export$__embind_initialize_bindings",
    "export": "_embind_initialize_bindings",
    "reaches": []
 },

I can fix this issue by manually editing this intermediate file and changing this entry to:

   {
    "name": "emcc$export$__embind_initialize_bindings",
    "export": "_embind_initialize_bindings",
    "reaches": [],
    "root": true
  }

My guess: _embind_initialize_bindings should be marked with root: true but for some reason is not.

Another workaround is manually exporting this function via:
EXPORTED_FUNCTIONS=_main,__embind_initialize_bindings"
but I believe it should not be needed.

This issue is similiar to: #21844

[kripken]

Metadce can strip things that are not used, so somehow it is not seeing a use of that function, is my best guess. Do you have a testcase showing the issue that we can investigate?

cc @brendandahl

[sbc100]

@laminowany can you share more details about your use case? What link flags are you using? I assume you are using pthreads since that is the only place _embind_initialize_bindings is called.

[laminowany]

I don't really have minimal reproducible case yet, I was trying to build https://github.com/mitchcurtis/slate with Qt dev built from source.

Linker flags are following:
em++.py -O3 -DNDEBUG -s MODULARIZE=1 -s EXPORT_NAME=app_entry -s EXPORTED_RUNTIME_METHODS=UTF16ToString,stringToUTF16,JSEvents,specialHTMLTargets,FS,callMain -s PTHREAD_POOL_SIZE=4 -s INITIAL_MEMORY=50MB -s MAXIMUM_MEMORY=4GB -s MAX_WEBGL_VERSION=2 -s FETCH=1 -s WASM_BIGINT=1 -s STACK_SIZE=5MB -pthread -s ALLOW_MEMORY_GROWTH -sASYNCIFY_IMPORTS=qt_asyncify_suspend_js,qt_asyncify_resume_js -s ERROR_ON_UNDEFINED_SYMBOLS=1 -Wno-pthreads-mem-growth

[sbc100]

I don't see either -lembind or --bind on the command line there, which mean that program doesn't look like its using embind at all.

The resulting code should therefor not contains a call to _embind_initialize_bindings in the pthread startup code:

emscripten/src/runtime_pthread.js

Lines 168 to 175 in bd2de9c

	#if EMBIND
	#if PTHREADS_DEBUG
	dbg(`worker: Pthread 0x${_pthread_self().toString(16)} initializing embind.`);
	#endif
	// Embind must initialize itself on all threads, as it generates support JS.
	// We only do this once per worker since they get reused
	__embind_initialize_bindings();
	#endif // EMBIND

.

Can you confirm where the call from _embind_initialize_bindings is coming from? Is it the pthread startup code, or somewhere else?

If possible perhaps you can bisect to figure out which change caused the regression: https://emscripten.org/docs/contributing/developers_guide.html#bisecting