relocation R_WASM_MEMORY_ADDR_TLS_SLEB cannot be used against __THREW__ in non-TLS section: .bss
#12941
Comments
|
A couple quick questions about this issue:
|
|
It looks like |
|
When you report an issue like its its often useful to include the full failing a command along with the full output/error of that command. Are you able to do that? I understand that sometimes its not possible for IP reasons. |
Yes.
No.
I've created a conan package using this recipe
How to do that?
|
|
If you can see the full error message it should contain within it the full wasm-ld command which contains the full path to compiler-rt bring used. |
Sorry, that is great and very useful. But I was referring the error message included in the bug report itself. The |
This is the full output of It appears to use |
|
Also the output when LTO is enabled: Also, feel free to play with the repository I've prepared for demonstrating the crash. |
|
It looks like |
|
We are trying to support the linking thread-supporting libraries into non-threaded application, so maybe we can avoid this error message. @tlively, this is the kind of thing we want to allow right? |
|
I think this might be something we can/should fix upstream in llvm.. |
I doubt. It's mostly original OpenCV's cmake build script, which correctly enables threads if target platform supports it. Also keep in mind that the very same version of OpenCV with same CMake build script works correctly with emscripten 1.39.16 and fastcomp backend (something we still use in production and are wishing to move away from). I've built now with |
|
So, basically, only We still cannot use threading in WASM as mobile browsers don't support it. |
OK, this comes from the original OpenCV's build script: if(X86 AND NOT MINGW64 AND NOT X86_64 AND NOT APPLE)
add_extra_compiler_option(-march=i686)
endif()in |
|
I've commented-out the above cmake snippet and it didn't help - same error still occurs. |
|
OK, now I see, OpenCV's build script appends |
|
Indeed, and its something we want to support .. I think we can find a way to have the linker accept this kind of thing. |
|
Anyway, the resulting WASM won't work on Safari and Android Chrome, would it? Those browsers don't support wasm threads anyway, so I definitely don't want any thread-related stuff in my binary. Thank you for the hints and guidelines. The sample in the repro repository now works (after I remove |
|
The idea is that the resulting binary will still be effectively single-thread, even though it contains atomic instructions. Thanks to a recent addition such binaries should run on non-thread-supported browser: WebAssembly/threads#144. At least the is the idea. But its certainly safer to avoid compiling with thread support in the first place. |
|
😂 It appears that removing |
|
Yes, we would like to support this without errors if possible. Right now
|
|
Couldn't we maybe address this in the linker? The linker already handles TLS data in the data linking case by kind of lowering it away, right? In that case does it matter than |
|
I guess it would mean merging TLS and regular data and having the internal/fake |
|
In mixed builds, the method of accessing the variable will be different in different compilation units. When -pthread is enabled and the variables are thread-local, accesses are to a global plus an offset. When -pthread is not enabled, accesses do not involve the global. I guess we could solve this in the linker by generating a TLS base of 0 and setting the TLS offsets to be equal to the actual addresses or something like that. Converting TLS to normal data in the linker like that would work when the output does not use a shared memory, but it would not be possible to go the other direction and convert normal data to TLS when the output does use a shared memory. Due to that asymmetry, I don't think this is a problem we should attempt to solve in the linker. |
|
IIUC we do already effectively convert TLS to normal data in the linker, right? Isn't that exactly what https://reviews.llvm.org/D91115 does? The limitation is that all the object files have to agree on the TLS-ness of a given symbol. I guess the question is, is it worth trying to remove that restriction? It seems like your are saying one. |
Oh right, I forgot about that change 👍
My understanding is that it would be possible to remove that restriction only for links without shared memory. I think it would be surprising for users if the type of memory used in the link controlled whether or not compilation units were allowed to disagree about the TLS-ness of a variable. |
|
Right, I'm only talking about single-theads links (without shared memory). The win is normal single-threaded users to not having to go though all your sub-projects build systems to try to remove any stray But maybe its easier/better to try to improve the error reporting in this case? |
|
Hmm, that's a good point. The general problem of trying to allow mixed pthread and non-pthread code only works if the result is single-threaded, so this particular problem isn't special in that way. I think I'm convinced that removing this restriction would be useful, then 👍 |
|
This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant. |
While building our code with LTO enabled, I get this link error:
So far I've traced that this happens as soon as I link in
libopencv_imgcodecs.ain my app, even though no code ever calls any function from it. My app also uses google test framework. The whole code is compiled with-fno-exceptions, except thelibopencv_imgcodecs.amodule, which internally uses exceptions.To work around the issue, I can either not link to
libopencv_imgcodecs.aor compile google test framework with-fexceptions.However, if I add a call to a function from
libopencv_imgcodecs.a, linker fails even with LTO disabled with following message:This happens no matter if exceptions are enabled or disabled in Google Test Framework.
I've googled this error message and found this LLVM pull request by @sbc100 as the one that adds that message to the LLD.
I hope I'll be able to reproduce this using entirely open source components (OpenCV and Google Test Framework), without any proprietary code. If I succeed, I'll share the code here.
I am using emscripten 2.0.9 on MacOS Big Sur.
The text was updated successfully, but these errors were encountered: