Wasm compilation error "Fatal: GOT.func entry with no import/export" when running wasm-emscripten-finalize #8995
Comments
|
Him, this does look like a bug in binaryen. However, |
|
I checked, it doesn't look like I'm using any of those options. |
|
Can you look at how you build your libraries: out/canvaskit_wasm/libskottie.a out/canvaskit_wasm/libsksg.a out/canvaskit_wasm/libparticles.a out/canvaskit_wasm/libskshaper.a out/canvaskit_wasm/libharfbuzz.a out/canvaskit_wasm/libicu.a out/canvaskit_wasm/libskia.a /tmp/emscripten_temp_OdtPcF/bind_5.o /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libfreetype.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libpng.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libz.a Check that they are not using |
|
I just checked, i couldn't see the |
|
An FYI, this is compiling fine with the fastcomp llvm backend. Only when i switch to llvm upstream is when i get these issues. |
|
Do you have a repro case for this? |
|
@sbc100 i may have one repro case that @kripken would me to document here : get micropython master + a pending PR micropython/micropython#4875 for javascript port tweaked for raising the same bug with upstream Here's the steps i followed : should lead to something like from what i get it's caused by either SIDE_MODULE / MAIN_MODULE / -fPIC |
|
Can you try with the very latest llvm. I'm hoping this will be fixed with: https://reviews.llvm.org/D65922 |
|
@sbc100 i'd gladly try to do that, but i have not clue where to begin with apart from |
|
You can get a very recent llvm build using the tip-of-tree feature in the emsdk (that's how emscripten CI works). Do |
|
I confirmed that gets LLVM that has that change. |
|
thx, there's some changes but not so good ...
note to self:
edit/ how can i get the exact llvm revision emsdk used so i can give it with reports ? was clang version 10.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project 2346b92f2bff05ef9d83706787bd38e32e0079c5) |
|
Ok, sorry I was a little confused. I thought you are trying to produce static build. I didn't realize you were interested in the MAIN_MODULE/SIDE_MODULE use case. I've replied below..
Thats too bad, this is exactly the case I was hoping to have fixed. A fix for this should be easy if I can get a reasonable sizes repro.
OK this is the normal dynamic linking case and is almost certainly an emscripten or binaryen bug. Again should be easy enough to fix with a reasonable sized repro case. @kripken that symbol name looks familiar, isn't that the one that is double imported? I guess this is a binaryen bug.
Thats right. All code in the main module and side module needs to be position independent (at least right now).
If I'm reading this right asynify is the problem here, no the llvm back end per-say? Perhaps worth opening a separate issue for that. I'm not sure if that expected or not.
|
|
I had the same error on a different project. I changed to newest LLVM (032e1fdcd47ef98936c88aa30571c6a713179a46). After this it throws the following callstack: wasm-ld: llvm-project.git/lld/wasm/Symbols.cpp:115: void lld::wasm::Symbol::setGOTIndex(uint32_t): Assertion `gotIndex == INVALID_INDEX' failed. |
|
The longjmp name may indicate this is related to WebAssembly/binaryen#2292 it's possible that fixes this issue too, as it removes the extra longjmp import which causes problems. The new 1.38.42 from today contains that fix, so trying there would see. If that's not it, if you can provide a full testcase I can reproduce it with locally then I can debug that. |
|
@kripken, i see no change with micropython codebase on 1.38.42-upstream failMAIN_MODULE -fPIC +link lib static (SIDE_MODULE) + -fPIC with fail-fPIC +link lib static (SIDE_MODULE) + -fPIC not possible atm( see R_WASM_MEMORY_ADDR_LEB as @sbc100 said earlier ) MAIN_MODULE +link lib static (SIDE_MODULE) + -fPIC ok but crippled for ffi/dlopencomplete static linking. last case is probably fine from MicroPython point of view but that would not be very constructive for emsdk future. ( STATIC=1 at least would be great since small dlopened wasm python modules are wanted , not a problem for libmicropython.wasm not shared since it's too big for some browsers ) clang version 10.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project edfaee08115376467d1c95573de991aebfdaeb42) |
|
Using the tot-upstream branch, I see that the same issue still happens with skia's Canvaskit. archives are created without indices, and after manually adding the indices using ranlib, the following error is returned: #0 0x00007f727dba0724 PrintStackTraceSignalHandler(void*) (/render/third_party/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6e2724) In order to repro, the skia repo can be cloned and call the modules/canvaskit/compile.sh script. |
|
@Shachlan I'm looking at the crash now. BTW the ranlib issue can be solved by adding Also |
|
Thanks @sbc100! Is there anything I can do to help with the investigation? |
|
Fix is in progress in https://reviews.llvm.org/D66784. Its not ready yet but I've found the issue. |
|
IIUC the remaining issues you are seeing here are a duplicate of #9317. If I'm correct lets close this one in favor of 9217 |
|
The fix for the signature mismatch warnings is here: https://reviews.llvm.org/D67015 |
Summary: This a follow up on: https://reviews.llvm.org/D62153 Handle the case where there are multiple object files that contain undefined references to the same function. We only generate a function variant if the existing symbol is directly called. See: emscripten-core/emscripten#8995 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67015 git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@370509 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This a follow up on: https://reviews.llvm.org/D62153 Handle the case where there are multiple object files that contain undefined references to the same function. We only generate a function variant if the existing symbol is directly called. See: emscripten-core/emscripten#8995 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67015 llvm-svn: 370509
|
Thanks @sbc100 ! Any news on the -fPIC static linking issue? |
|
@Shachlan look at #9317 (comment) and earlier for how @Beuc managed to test proposed patches, sadly i have very bad internet and can't get 70 GiB of stuff to test https://reviews.llvm.org/D67015 |
|
Not yet. For now I still recommend trying to remove |
|
D67015 is not ready yet |
|
Looks like (If so, do we have tests for this now?) |
|
D67015 only fixes the spurious signature mismatches. I think the other issue which manifests as However that issue is better described in #9317. So closing this now as duplicate of that issue. |
|
Thanks! When do you think it will be integrated for consumption via emsdk? |
|
What issue are you asking about? The spurious signature mismatches issue is already available I latest I believe. As is the The only remaining issue is #9317 ( |
|
Thanks, I was referring to the D67015 fix, but I seem to have misunderstood how emsdk works - I wrongly assumed that fixes to emscripten need to be also merged into emsdk. |
|
We do need to cut a new emscripten release before you will see any changes appear in To find out what is in a given release Is a sadly fairly involved procedure: You start by looking at: Those hashs are revisions in https://chromium.googlesource.com/emscripten-releases/+/refs/heads/master/. To see what is in 1.38.45 you can look at the DEPS file at that revision: There you see llvm revision: f145456fc4a4a9938630daab41969da2be8208db And this revisions does indeed include https://reviews.llvm.org/D67015. Phew.. thats harder than it should be.. |
|
I believe all the the issues that have been raise are now fixed in upstream llvm. What issues do you have the remain? Is this issue still occurring for you with the latest llvm? |
|
i triplechecked for SIDE MODULE not being present, added -fPIC everywhere but wasm-ld failed at program linking and don't have much other clue than the linker line seems perfectly legit https://wyz.fr/paste/5JB/raw. removing either of those will not solve the dl* functions requirements i have for FFI. Pipeline was : note that i don't have control on .o compilation but i can extract info if needed.
i'll retry with tot-upstream in a few hours, but problem was already there few days before kripken asked for the go of tagging, btw is it ok to open issues for tot-upstream ? or better address someone specific on IRC for that, as i only reported on IRC ( i'm rarely sure of my findings all of that is very experimental for me ): |
|
OK, so the "linking two different copies of libc" looks like real and seperate issue. Could you open a bug for that? The SDL2 issue (-pie + -r) was fixed in #9510 IRC is a fine place to discuss issues, but I for one might not see it unless you mention me there. If nobody gets back to you feel free to open issues here. |
|
I can still produce the original error in this issue with latest version ( |
I'm trying to compile the skia's Canvaskit to wasm using emscripten 1.38.38 and LLVM upstream backend. Initially, i faced several linker errors from wasm-ld, but which could be resolved for now by manually using llvm-ranlib to index the different .a archives. (Errors looked like
wasm-ld: error: out/canvaskit_wasm_debug/libskottie.a: archive has no index; run ranlib to add one)However, now I'm facing an error
With the fatal error coming from wasm-emscripten-finalize. I wondered if this is because of #8905 , as this hasn't been updated in latest-upstream, only in incoming branch.
Any help would be appreciated.
The text was updated successfully, but these errors were encountered: