Large __wasm_apply_data_relocs function

[alexander-veselov]

We were finally able to somehow run the application using dynamic libraries. But we decided that we want to make some of the libraries static, since we don't plan to load them using dlopen.

Everything works if you build all the libraries statically (without using MAIN_MODULE). It also works if all libraries are dynamic (using MAIN_MODULE).

But if we try to make some libraries dynamic and some static, then the following runtime error occurs:

Runtime error: Uncaught (in promise) RuntimeError: Aborted(CompileError: WebAssembly.instantiate(): size 10345817 > maximum function size 7654321 @+5462385). Build with -sASSERTIONS for more info.

I found that the problem is in __wasm_apply_data_relocs function.

Command: wasm-objdump -j code -x file.wasm
Output: - func[901] size=10345817 <__wasm_apply_data_relocs>

Can this be fixed somehow? What affects the size of this function?

[sbc100]

This function is proportional to the number of data relocation in you have in your program, which occur when static data contains address (e.g. int* foo = &bar). The most common cause of many relocation is C++ vtables where every entry requires a relocation.

What version of emscripten are you using? We made some improvements in this area recently so please try the latest vesion?

If you can use MAIN_MODULE=2 instead of MAIN_MODULE=1 that should help a lot too since then we can eliminate dead code.

We do have a tracking bug for this issue: llvm/llvm-project#55608

[alexander-veselov]

Hello, sorry for taking so long to reply, I had day offs.

I used the latest version at that time 3.1.15.

We'd like to use MAIN_MODULE=2, but we can't because EMSCRIPTEN_KEEPALIVE can't be applied to classes. I know that we can use this for every method, it does not suit us. This is not our main problem right now, but it would be nice if we could use this for an entire class.

I want to focus on the specific problem that I described earlier. If you build ALL libraries as dynamic, then the size of __wasm_apply_data_relocs is 3860193. But if you build all libraries STATICALLY except for ONE (build one dynamically), then the size of the function grows catastrophically (up to 10345817). Is this the expected behavior?

It's good that there is already a bug for a similar problem. How problematic would it be for you to try to split this function into N parts? (or at least 2 for beginning)

[sbc100]

I think what happens when you do that is that there is simply more code in the main module and the size of __wasm_apply_data_relocs is proportional the number amount of static data which in turn is proportional (in C++ programs) to the number of vtables.

It would be good to fine a way to try to reduce per-relocation size of __wasm_apply_data_relocs but I don't have any great ideas. The only thing I can think of is to split it up in to chunks.

Alternatively, fixing #12682 would also help too.

[alexander-veselov]

It would be great if you split it. At least there will be no error.