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

ODR vialotion in mlir-cpu-runner + libmlir_async_runtime.so #61856

Closed
banach-space opened this issue Mar 30, 2023 · 5 comments
Closed

ODR vialotion in mlir-cpu-runner + libmlir_async_runtime.so #61856

banach-space opened this issue Mar 30, 2023 · 5 comments
Labels

Comments

@banach-space
Copy link
Contributor

banach-space commented Mar 30, 2023

Hi,

The following RUN line from async-group.mlir leads to ODR violation:

// RUN: | mlir-cpu-runner  \
// RUN:     -e main -entry-point-result=void -O0 \
// RUN:     -shared-libs=%mlir_c_runner_utils  \
// RUN:     -shared-libs=%mlir_runner_utils  \
// RUN:     -shared-libs=%mlir_async_runtime  \

Specifically, on my development AArch64 machine running Linux (I doubt the platform actually matters), I see the following:

$ nm libmlir_async_runtime.so | grep EnableABIBreakingChecks

000000000038cb80 B _ZN4llvm23EnableABIBreakingChecksE

$ nm mlir-cpu-runner | grep EnableABIBreakingChecks
000000000474364c B _ZN4llvm23EnableABIBreakingChecksE

And indeed, ASan is able to identify the invocation from async-group.mlir as ODR violation, see sanitizer-x86_64-linux-fast.

This patch implements a workaround that helps silence ASan (there's also a bit more discussion there):

However, that's not a proper solution. To me it feels that libmlir_async_runtime.so should be refactored to fix this, but this isn't really my area of expertise and recommendations (as well as volunteers) are welcome :)

CC @lhames @hctim

-Andrzej

@llvmbot
Copy link
Member

llvmbot commented Mar 30, 2023

@llvm/issue-subscribers-mlir

@joker-eph
Copy link
Collaborator

I think that this indicates that libLLVMSupport is statically linked in the two libraries.

One way to handle it could be to link this as an internal library (hide all symbols): the libmlir_async_runtime.so should not need to expose more than handful of entry points?

@banach-space
Copy link
Contributor Author

I think that this indicates that libLLVMSupport is statically linked in the two libraries.

Yeah, that's the case:

cmake -DCMAKE_CXX_FLAGS="-Wl,--trace-symbol=_ZN4llvm23EnableABIBreakingChecksE"
ninja -v  mlir_async_runtime
/usr/bin/clang++-14 -fPIC -Wl,--trace-symbol=_ZN4llvm23EnableABIBreakingChecksE -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Werror=mismatched-tags -Werror=global-constructors -O3 -DNDEBUG  -Wl,--gdb-index -fuse-ld=lld  -Wl,-z,defs -Wl,-z,nodelete -Wl,--color-diagnostics   -Wl,--gc-sections -shared -Wl,-soname,libmlir_async_runtime.so.17git -o lib/libmlir_async_runtime.so.17git tools/mlir/lib/ExecutionEngine/CMakeFiles/mlir_async_runtime.dir/AsyncRuntime.cpp.o  -Wl,-rpath,"\$ORIGIN/../lib"  lib/libLLVMSupport.a  -lrt  -ldl  -lm  /usr/lib/aarch64-linux-gnu/libz.so  /usr/lib/aarch64-linux-gnu/libzstd.so  /usr/lib/aarch64-linux-gnu/libtinfo.so  lib/libLLVMDemangle.a && :
lib/libLLVMSupport.a(ABIBreak.cpp.o): definition of _ZN4llvm23EnableABIBreakingChecksE

One way to handle it could be to link this as an internal library (hide all symbols): the libmlir_async_runtime.so should not need to expose more than handful of entry points?

So I think that this is already meant to be happening:

set_property(TARGET mlir_async_runtime PROPERTY CXX_VISIBILITY_PRESET hidden)

Just to confirm - this would "hide" the symbols, but there still would be multiple definition of EnableABIBreakingChecks in:

/ RUN: | mlir-cpu-runner  \
// RUN:     -e main -entry-point-result=void -O0 \
// RUN:     -shared-libs=%mlir_c_runner_utils  \
// RUN:     -shared-libs=%mlir_runner_utils  \
// RUN:     -shared-libs=%mlir_async_runtime 

@joker-eph
Copy link
Collaborator

Just to confirm - this would "hide" the symbols, but there still would be multiple definition of EnableABIBreakingChecks in:

Yes, libSupport is an implementation detail of mlir_async_runtime I believe, we can hide a private copy in there.

@banach-space
Copy link
Contributor Author

This took a bit of digging, but does the job:

target_link_options(mlir_async_runtime PRIVATE "-Wl,-exclude-libs,ALL")

I'll update https://reviews.llvm.org/D146935 accordingly. Does this make sense to you?

gysit pushed a commit to nextsilicon/llvm-project that referenced this issue Apr 27, 2023
This patch is primarily about the change in
"mlir/tools/mlir-cpu-runner/CMakeLists.txt". LLJIT needs access to
symbols (e.g. llvm_orc_registerEHFrameSectionWrapper) that will be
defined in the executable when LLVM is linked statically. This change is
consistent with how other tools within LLVM use LLJIT. It is required to
make sure that:
```
 $ mlir-cpu-runner --host-supports-jit
```
correctly returns `true` on platforms that do support JITting (in my
case that's AArch64 Linux).

The change in "mlir/lib/ExecutionEngine/CMakeLists.txt" is required to
avoid ODR violations when symbols from `mlir-cpu-runner` are exported
and when loading `libmlir_async_runtime.so` in `mlir-cpu-runner`.
Specifically, to avoid `EnableABIBreakingChecks` being defined twice.
For more context:
  * llvm#61712
  * llvm#61856
  * https://reviews.llvm.org/D146935 (this PR)

This change relands ccdcfad

Fixes llvm#61856

Differential Revision: https://reviews.llvm.org/D146935
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants