Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasm-ld regression in 3.1.64: symbol type mismatch #23501

Closed
hoodmane opened this issue Jan 25, 2025 · 5 comments · Fixed by llvm/llvm-project#124619
Closed

wasm-ld regression in 3.1.64: symbol type mismatch #23501

hoodmane opened this issue Jan 25, 2025 · 5 comments · Fixed by llvm/llvm-project#124619

Comments

@hoodmane
Copy link
Collaborator

In Emscripten 3.1.64, we start getting errors in building several libraries like follows:

wasm-ld: error: symbol type mismatch: crc32_z                                   
>>> defined as WASM_SYMBOL_TYPE_SECTION in                                      
/root/repo/packages/.libs/lib/libnetcdf.a(libdispatch_la-dcrc32.o)              
>>> defined as WASM_SYMBOL_TYPE_FUNCTION in                                     
/root/repo/packages/.libs/lib/libhdf5.so

Here's what wasm-ld outputs as the --repro:
a.tar.gz

wasm-ld @response.txt works fine with wasm-ld 3.1.63 but breaks on 3.1.64.

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.64 (a1fe390)

@ryanking13
Copy link
Contributor

ryanking13 commented Jan 27, 2025

I did some bisection, and this change looks related: llvm/llvm-project#75242 (cc: @sbc100)

It seems to add two new checks:

  1. function signature mismatch check:

We (Pyodide) faced new signature mismatches in a few packages, and I think it is what the PR intended.

  1. symbol type mismatch check:

This seems to be a secondary change in the PR, but it's the thing causing this issue.

Happens here: https://github.com/sbc100/llvm-project/blob/000519d1a3597cfb7e42b23a33f0989ad3ef1e4b/lld/wasm/SymbolTable.cpp#L370-L374

But I don't understand why it is misjudging a FUNCTION symbol as a SECTION.

@sbc100
Copy link
Collaborator

sbc100 commented Jan 27, 2025

@ryanking13 are you also seeing mismatched between FUNCTION and SECTION symbols? I think llvm/llvm-project#75242 should only relate to shared libraries (which is it likely effects you), but this but looks like its not related to shared libraries, just simply object files.

@sbc100
Copy link
Collaborator

sbc100 commented Jan 27, 2025

Sorry I misread the OP, this is indeed related to shared symbols.

@sbc100
Copy link
Collaborator

sbc100 commented Jan 27, 2025

Fix in flight on the llvm side: llvm/llvm-project#124619

@ryanking13
Copy link
Contributor

Thanks for the quick answer and fix!

github-actions bot pushed a commit to arm/arm-toolchain that referenced this issue Jan 29, 2025
…acing lazy symbols (#124619)

The rule here, which I'm copying from the ELF linker, is that shared
library symbols should take presence, unless the symbol has already be
extracted from the archive. e.g:

```
$ wasm-ld foo.a foo.so ref.o  // .so wins
$ wasm-ld foo.a ref.o foo.so  // .a wins
```

In the first case the shared library takes precedence because the lazy
symbol is replaced by the .so symbol before it is extracted from the
archive. In the second example the ref.o file causes the archive to be
exracted before the .so file is processed, so in that case the archive
file wins.

Fixes: emscripten-core/emscripten#23501
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants