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

Get the ASAN toolchain working again #7604

Merged
merged 12 commits into from
Jun 23, 2023
Merged

Get the ASAN toolchain working again #7604

merged 12 commits into from
Jun 23, 2023

Conversation

steven-johnson
Copy link
Contributor

@steven-johnson steven-johnson commented Jun 1, 2023

Various fixes to enable ASAN to finally work (linux x64 only).

Note that this found several one real ASAN failure in the Anderson2021 autoscheduler tests, which is not fixed yet; I'll fix thus in a subsequent PR.

Various fixes to enable ASAN to finally work (linux x64 only).

Note that this found several ASAN failures in the Anderson2021 autoscheduler tests, which are *not* fixed yet; I'll fix thus in a subsequent PR.
@steven-johnson
Copy link
Contributor Author

(Note that I'm pushing some temporary debugging code here to try to catch a failure that so far only repros on the buildbots, but not locally -- please ignore when reviewing, for now at least)

steven-johnson added a commit that referenced this pull request Jun 5, 2023
(Harvested from #7604 to land separately)
@alexreinking
Copy link
Member

I'm going to try this locally before doing a full review. There are a few things here that are raising alarm bells for certain toolchain configurations.

@steven-johnson
Copy link
Contributor Author

I'm going to try this locally before doing a full review. There are a few things here that are raising alarm bells for certain toolchain configurations.

Thanks. Everything about ASAN (or really, any of the sanitizers) is pretty ticklish, due to the combination of our unorthodox build setup (eg building to bitcode) and CMake being CMake.

steven-johnson added a commit that referenced this pull request Jun 6, 2023
* Fix PCH build failures

(Harvested from #7604 to land separately)

* Update CMakeLists.txt
@alexreinking
Copy link
Member

When building with clang 16, I get the following error:

[59/1220] Linking CXX executable test/correctness/correctness_float16_t
FAILED: test/correctness/correctness_float16_t 
: && /local/mnt2/workspace/areinkin/.local/llvm-16/bin/clang++ -fsanitize=address -fuse-ld=/local/mnt2/workspace/areinkin/.local/llvm-16/bin/ld.lld test/CMakeFiles/Halide_terminate_handler.dir/common/terminate_handler.cpp.o test/correctness/CMakeFiles/correctness_float16_t.dir/float16_t.cpp.o -o test/correctness/correctness_float16_t  -Wl,-rpath,/local/mnt2/workspace/areinkin/dev/Halide/build/clang-16/src  src/libHalide.so.16.0.0 && :
ld.lld: error: undefined symbol: __extendhfsf2

Things I did that allowed the build to finish:

  1. Link to the Clang compiler runtime via -rtlib=compiler-rt.
  2. Set -march=haswell in this toolchain (CMAKE_{C,CXX}_FLAGS_INIT) so that native fp16 operations are available and the __extendhfsf2 function isn't emitted in the first place.
  3. Check that a simple test program that uses _Float16 builds; if not, disable the test.

I don't recommend (1)... The default is libgcc, which is sensible for distributing binaries; no guarantee downstream systems have compiler-rt built.

I'm partial to a mix of 2 and 3.

@steven-johnson
Copy link
Contributor Author

I thought that we had to explicitly link to compiler-rt anyway for ASAN to work properly. (Maybe I'm confusing it with something?)

FWIW, I didn't even test with LLVM16 -- my assumption here is that we'll only do ASAN builds with top-of-tree, so as long as it works with LLVM/Clang17+, we're fine.

@alexreinking
Copy link
Member

alexreinking commented Jun 20, 2023

Okay, if Clang 17 doesn't need any of this, then I'm cool with the change.

Well, almost -- there's more in here than just the toolchain changes.

Copy link
Member

@alexreinking alexreinking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm proposing a less ad-hoc extension point that feels better to send downstream. I can open a PR-to-PR if you agree with the change, but would prefer not to do this work.

Comment on lines 251 to 256
if (Halide_SHARED_ASAN_RUNTIME_LIBRARY)
# ASAN's Leak detector will report that we leaked all the PyBind11
# Module-support code, so disable it here.
set(EXTRA_ENV_VARS ASAN_OPTIONS=detect_leaks=0 ${Halide_SANITIZER_ENV_VARS})
endif ()
set(GENERATOR_CMD ${CMAKE_COMMAND} -E env PYTHONPATH=${PYTHONPATH} ${EXTRA_ENV_VARS} ${Python3_EXECUTABLE} $<SHELL_PATH:${py_src}>)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this is code is part of our downstream package interface, the Halide_SHARED_ASAN_RUNTIME_LIBRARY variable would need to be documented. I think a more flexible design would be to add a Halide_PYTHON_LAUNCHER variable that works like the familiar CMAKE_CXX_COMPILER_LAUNCHER variable.

To implement that, this code would be:

Suggested change
if (Halide_SHARED_ASAN_RUNTIME_LIBRARY)
# ASAN's Leak detector will report that we leaked all the PyBind11
# Module-support code, so disable it here.
set(EXTRA_ENV_VARS ASAN_OPTIONS=detect_leaks=0 ${Halide_SANITIZER_ENV_VARS})
endif ()
set(GENERATOR_CMD ${CMAKE_COMMAND} -E env PYTHONPATH=${PYTHONPATH} ${EXTRA_ENV_VARS} ${Python3_EXECUTABLE} $<SHELL_PATH:${py_src}>)
# TODO: when upgrading to CMake 3.24+ add `--` before `${Halide_PYTHON_LAUNCHER}`
set(GENERATOR_CMD ${CMAKE_COMMAND} -E env PYTHONPATH=${PYTHONPATH} ${Halide_PYTHON_LAUNCHER} ${Python3_EXECUTABLE} $<SHELL_PATH:${py_src}>)

Then, in our toolchain file, we could set:

set(
    Halide_PYTHON_LAUNCHER
    ${CMAKE_COMMAND} -E env ASAN_OPTIONS=detect_leaks=0 LD_PRELOAD=${Halide_SHARED_ASAN_RUNTIME_LIBRARY}
)

test/CMakeLists.txt Outdated Show resolved Hide resolved
set(Halide_SHARED_ASAN_RUNTIME_LIBRARY "${Halide_SHARED_ASAN_RUNTIME_LIBRARY}"
CACHE FILEPATH "Library to preload when running Python tests.")

set(Halide_SANITIZER_ENV_VARS "LD_PRELOAD=${Halide_SHARED_ASAN_RUNTIME_LIBRARY}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
set(Halide_SANITIZER_ENV_VARS "LD_PRELOAD=${Halide_SHARED_ASAN_RUNTIME_LIBRARY}")
set(
Halide_PYTHON_LAUNCHER
${CMAKE_COMMAND} -E env ASAN_OPTIONS=detect_leaks=0 LD_PRELOAD=${Halide_SHARED_ASAN_RUNTIME_LIBRARY}
)

As described above.

Comment on lines 72 to 74
if (Halide_SANITIZER_ENV_VARS)
list(PREPEND ARG_ENVIRONMENT ${Halide_SANITIZER_ENV_VARS})
endif ()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (Halide_SANITIZER_ENV_VARS)
list(PREPEND ARG_ENVIRONMENT ${Halide_SANITIZER_ENV_VARS})
endif ()

Then, below (GitHib won't let me comment there 😠), in the call to add_test replace

COMMAND Python3::Interpreter

with

COMMAND ${Halide_PYTHON_LAUNCHER} "${Python3_EXECUTABLE}"

@@ -42,6 +42,7 @@ if (WITH_PYTHON_BINDINGS)
set_tests_properties(li2018_gradient_autoscheduler_test_py PROPERTIES
DEPENDS li2018_test
LABELS "li2018;autoschedulers;auto_schedule"
ENVIRONMENT "${Halide_SANITIZER_ENV_VARS}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ENVIRONMENT "${Halide_SANITIZER_ENV_VARS}"

Same deal with add_test(... COMMAND Python3::Interpreter ...) above. Use the Halide_PYTHON_LAUNCHER variable.

@alexreinking alexreinking added the release_notes For changes that may warrant a note in README for official releases. label Jun 21, 2023
alexreinking and others added 2 commits June 23, 2023 10:47
* Use new Halide_PYTHON_LAUNCHER to set env vars

* Update CMake docs for Halide_SANITIZER_ENV_VARS

---------

Co-authored-by: Alex Reinking <areinkin@qti.qualcomm.com>
@steven-johnson
Copy link
Contributor Author

With your changes merged, is this good to go now, or are more changes needed?

Copy link
Member

@alexreinking alexreinking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM now

@steven-johnson steven-johnson merged commit 2a93cb0 into main Jun 23, 2023
@steven-johnson steven-johnson deleted the srj/fix-asan branch June 23, 2023 20:53
ardier pushed a commit to ardier/Halide-mutation that referenced this pull request Mar 3, 2024
* Fix PCH build failures

(Harvested from halide#7604 to land separately)

* Update CMakeLists.txt
ardier pushed a commit to ardier/Halide-mutation that referenced this pull request Mar 3, 2024
* Get the ASAN toolchain working again

Various fixes to enable ASAN to finally work (linux x64 only).

Note that this found several ASAN failures in the Anderson2021 autoscheduler tests, which are *not* fixed yet; I'll fix thus in a subsequent PR.

* Remove stuff that I didn't mean to check in

* Configure cuda-specific tests properly too

* trigger buildbots

* Update CodeGen_LLVM.cpp

* Update CodeGen_LLVM.cpp

* Fix sloppiness?

* Update CMakeLists.txt

* trigger buildbots

* Use Halide_PYTHON_LAUNCHER to implement ASAN toolchain fixes (halide#7657)

* Use new Halide_PYTHON_LAUNCHER to set env vars

* Update CMake docs for Halide_SANITIZER_ENV_VARS

---------

Co-authored-by: Alex Reinking <areinkin@qti.qualcomm.com>

---------

Co-authored-by: Alex Reinking <alex.reinking@gmail.com>
Co-authored-by: Alex Reinking <areinkin@qti.qualcomm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_notes For changes that may warrant a note in README for official releases.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants