Skip to content

[codex] Build libc++ with ASan enabled#666

Open
dzbarsky wants to merge 8 commits into
mainfrom
zbarsky/libcc-asan
Open

[codex] Build libc++ with ASan enabled#666
dzbarsky wants to merge 8 commits into
mainfrom
zbarsky/libcc-asan

Conversation

@dzbarsky

@dzbarsky dzbarsky commented Jul 2, 2026

Copy link
Copy Markdown
Member

Author: zbarsky-bot

Summary

libcxx.static and libcxx.shared now preserve //config:asan while runtime transitions reset every other sanitizer. The generated libc++ __config_site defines _LIBCPP_INSTRUMENTED_WITH_ASAN from //config:asan_enabled, so out-of-line std::string functions update ASan container poison state. asan_libcxx_container_overflow_test covers the -fno-exceptions short-to-long std::string transition from the bazel-playground external-include-paths reproducer.

On Linux, sanitizer_common_symbolizer_internal_object replaces the previous sanitizer_common_symbolizer_internal and @llvm-project//llvm:Symbolize linkage. cc_internal_symbolizer_object matches compiler-rt/lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh when COMPILER_RT_ENABLE_INTERNAL_SYMBOLIZER=ON: it builds private libc++ and libc++abi archives in the __InternalSymbolizer namespace, builds LLVM with Zlib enabled and Zstd and threads disabled, combines the bitcode, and internalizes every definition except the seven sanitizer symbolizer APIs. //config:internal_symbolizer selects libc++ headers for LLVM Symbolize even when the caller platform selects libstdc++. sanitizer_common_symbolizer_internal_object is enabled on Bazel 9, where external_include_paths keeps the private libc++ headers before the C library headers. On Bazel 8, sanitizer runtimes omit sanitizer_common_symbolizer_internal_object, asan_output_test uses @llvm//tools:llvm-symbolizer, and asan_libcxx_container_overflow_test is incompatible. The private namespace prevents internal symbolizer definitions from replacing ASan-annotated std::__1 definitions. asan_output_test verifies an internally symbolized main frame on Linux and retains the external @llvm//tools:llvm-symbolizer on macOS.

Validation

@dzbarsky dzbarsky force-pushed the zbarsky/libcc-asan branch from fdc5662 to 3182dc3 Compare July 2, 2026 17:24
@dzbarsky dzbarsky changed the title [codex] Build libc++ with sanitizers enabled [codex] Build libc++ with ASan enabled Jul 2, 2026
@dzbarsky dzbarsky requested review from cerisier and keith July 2, 2026 17:39
@dzbarsky dzbarsky marked this pull request as ready for review July 2, 2026 17:40
@dzbarsky dzbarsky force-pushed the zbarsky/libcc-asan branch from 3182dc3 to 7783d90 Compare July 3, 2026 16:07
@dzbarsky dzbarsky changed the title [codex] Build libc++ with ASan enabled [codex] Enable libc++ ASan container annotations Jul 3, 2026
Preserve //config:asan for libcxx.static and libcxx.shared while runtime transitions reset every other sanitizer. Generate _LIBCPP_INSTRUMENTED_WITH_ASAN from //config:asan_enabled so out-of-line std::string functions update ASan container poison state.

Stop linking sanitizer_common_symbolizer_internal and @llvm-project//llvm:Symbolize into sanitizer runtimes. LLVM upstream disables the internal symbolizer by default; the Bazel target exported ordinary std::__1 definitions from uninstrumented LLVM objects, which could replace the annotated libc++ definitions. Use the hermetic external llvm-symbolizer in asan_output_test instead.

Add asan_libcxx_container_overflow_test with -fno-exceptions to cover the external reproducer's short-to-long std::string transition.
@dzbarsky dzbarsky force-pushed the zbarsky/libcc-asan branch from 7783d90 to 2ef08b8 Compare July 4, 2026 01:34
@dzbarsky dzbarsky changed the title [codex] Enable libc++ ASan container annotations [codex] Build libc++ with ASan enabled Jul 4, 2026
dzbarsky added 6 commits July 3, 2026 23:46
Match build_symbolizer.sh by compiling private libc++ and libc++abi archives with LLVM bitcode, then internalize all definitions except the seven sanitizer symbolizer APIs.\n\nLink the object into Linux sanitizer runtimes so internal symbolization cannot replace ASan-annotated libc++ definitions with ordinary std::__1 definitions.
Select libc++ headers while building LLVM Symbolize and the private libc++ even when the caller platform selects libstdc++. Add the libc++ header paths before the C header paths in the stage1_hosted toolchain.\n\nPropagate target_compatible_with through exec_test so the Linux-only ASan container-overflow test is skipped on Windows.
… programs, (#671)

but not when building the runtimes themselves, as those are already
included so adding them again collides in the sandbox
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 this pull request may close these issues.

3 participants