Enable LLD_REPORT_UNDEFINED by default

[sbc100]

This makes undefined symbol errors more precise by including the name of the
object that references the undefined symbol.

Its also paves the way (in my mind anyway) for finally fixing reverse dependencies
in a salable way. See #15982. That PR uses an alternative script for the pre-processing
of dependencies but also fundamentally relies on processing JS libraries both before
and after linking.

The cost is about 300ms per link operation due to double processing of
the JS libraries, but results are cached so in practice this only
happens the first time a given link command is run (see #18326).

[sbc100]

This change has been behind a flag for a long time now and I think its finally ready to be the default.

[kripken]

Is this the change you mentioned adds 300ms to startup? (that we might want to profile)

[sbc100]

#18320 reduces the overhead to 275ms on my machine.

[kripken]

Speed sounds good!

[kripken]

Got it, thanks, lgtm.

[curiousdannii]

Sorry to raise an error just after you concluded there were no issues 😛 But you know, sometimes it takes a while to try updating dependencies.

I tried updating to 3.1.28+ and I now get errors for undefined symbols when an EM_JS function is defined in a library.

wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_lower_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_lower_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_upper_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_upper_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_title_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_title_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_canon_decompose_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_canon_decompose_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_canon_normalize_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_canon_normalize_uni

The EM_JS functions are defined in a library. If the functions are used in a executable then it makes these errors.

I'm not sure why, but another EM_ASYNC_JS function doesn't cause any errors. Maybe because it's only used by the same file?

Building with -sLLD_REPORT_UNDEFINED=0 fixes the issue.

[sbc100]

Sorry to raise an error just after you concluded there were no issues stuck_out_tongue But you know, sometimes it takes a while to try updating dependencies.

I tried updating to 3.1.28+ and I now get errors for undefined symbols when an EM_JS function is defined in a library.

wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_lower_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_lower_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_upper_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_upper_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_title_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_to_title_case_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_canon_decompose_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_canon_decompose_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_canon_normalize_uni
wasm-ld: error: libremglk.a(gi_dispa.c.o): undefined symbol: glk_buffer_canon_normalize_uni

I think the reason for this is that the EM_JS macro basically expands to a declaration of the EM_JS function as external with an __attribute__((import_name)) attached to it.

However, when you use it outside in other compilation units they don't see that declaration. Actually that sounds odd now that I say its since those attributes should probably attached to the final symbol.

In any case, I think the soltution that others have uses it to only call the EM_JS function within the file where they are defined, and then define small (difined) wrappers for them for use outside the compilation unit.

e.g. declare glk_buffer_to_title_case_uni_js as the EM_JS function then define a local glk_buffer_to_title_case_uni which then just calls it.

(I will investigate further to see if we can actually this fix with you having to change any code).

[curiousdannii]

Sure, that makes sense. If you can find a work around that would be great, otherwise that is a simple solution.

If you can't find a workaround, then the docs should also get an update saying that it's only safe to call a EM_JS etc function from the same file.