| commit | 0d7e64f5d2b45e2150a89390cfdc69b19b1493d9 | [log] [tgz] |
|---|---|---|
| author | David Justo <david.justo.1996@gmail.com> | Wed Jul 02 15:37:28 2025 -0700 |
| committer | GitHub <noreply@github.com> | Wed Jul 02 15:37:28 2025 -0700 |
| tree | 8522a4e866f31752b4b841245269e3c32d136b68 | |
| parent | 6550f28977b915f2a683dccfba67767a62933e82 [diff] |
[ASan][Windows] Honor asan config flags on windows when set through the user function (#122990) **Related to:** https://github.com/llvm/llvm-project/issues/117925 **Follow up to:** https://github.com/llvm/llvm-project/pull/117929 **Context:** As noted in the linked issue, some ASan configuration flags are not honored on Windows when set through the `__asan_default_options` user function. The reason for this is that `__asan_default_options` is not available by the time `AsanInitInternal` executes, which is responsible for applying the ASan flags. To fix this properly, we'll probably need a deep re-design of ASan initialization so that it is consistent across OS'es. In the meantime, this PR offers a practical workaround. **This PR:** refactors part of `AsanInitInternal` so that **idempotent** flag-applying steps are extracted into a new function `ApplyOptions`. This function is **also** invoked in the "weak function callback" on Windows (which gets called when `__asan_default_options` is available) so that, if any flags were set through the user-function, they are safely applied _then_. Today, `ApplyOptions` contains only a subset of flags. My hope is that `ApplyOptions` will over time, through incremental refactorings `AsanInitInternal` so that **all** flags are eventually honored. Other minor changes: * The introduction of a `ApplyAllocatorOptions` helper method, needed to implement `ApplyOptions` for allocator options without re-initializing the entire allocator. Reinitializing the entire allocator is expensive, as it may do a whole pass over all the marked memory. To my knowledge, this isn't needed for the options captured in `ApplyAllocatorOptions`. * Rename `ProcessFlags` to `ValidateFlags`, which seems like a more accurate name to what that function does, and prevents confusion when compared to the new `ApplyOptions` function.
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.