Google Git
Sign in
llvm / llvm-project / dbcd2e9330cd43921e13d8dce3d9b743ea2fe871
commitdbcd2e9330cd43921e13d8dce3d9b743ea2fe871[log] [tgz]
authorIvan Trofimov <i.trofimow@yandex.ru>Fri Feb 03 00:29:00 2023 -0800
committerTom Stellard <tstellar@redhat.com>Tue Apr 18 18:07:46 2023 -0700
treeeb1576caf709efae4759a0413d9caefe42dabf66
parentec006fb244fffadd84506885094974899dab06e7 [diff]
[runtimes][asan] Fix swapcontext interception

Resetting oucp's stack to zero in swapcontext interception is incorrect,
since it breaks ucp cleanup after swapcontext returns in some cases:

Say we have two contexts, A and B, and we swapcontext from A to B, do
some work on Bs stack and then swapcontext back from B to A. At this
point shadow memory of Bs stack is in arbitrary state, but since we
can't know whether B will ever swapcontext-ed to again we clean up it's
shadow memory, because otherwise it remains poisoned and blows in
completely unrelated places when heap-allocated memory of Bs context
gets reused later (see https://github.com/llvm/llvm-project/issues/58633
for example). swapcontext prototype is swapcontext(ucontext* oucp,
ucontext* ucp), so in this example A is oucp and B is ucp, and i refer
to the process of cleaning up Bs shadow memory as ucp cleanup.

About how it breaks:
Take the same example with A and B: when we swapcontext back from B to A
the oucp parameter of swapcontext is actually B, and current trunk
resets its stack in a way that it becomes "uncleanupable" later. It
works fine if we do A->B->A, but if we do A->B->A->B->A no cleanup is
performed for Bs stack after B "returns" to A second time. That's
exactly what happens in the test i provided, and it's actually a pretty
common real world scenario.

Instead of resetting oucp's we make use of uc_stack.ss_flags to mark
context as "cleanup-able" by storing stack specific hash. It should be
safe since this field is not used in [get|make|swap]context functions
and is hopefully never meaningfully used in real-world scenarios (and i
haven't seen any).

Fixes https://github.com/llvm/llvm-project/issues/58633

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D137654

(cherry picked from commit b380e8b68951776656f286ecd079e2f30981905e)
4 files changed
tree: eb1576caf709efae4759a0413d9caefe42dabf66
  1. .github/
  2. bolt/
  3. clang/
  4. clang-tools-extra/
  5. cmake/
  6. compiler-rt/
  7. cross-project-tests/
  8. flang/
  9. libc/
  10. libclc/
  11. libcxx/
  12. libcxxabi/
  13. libunwind/
  14. lld/
  15. lldb/
  16. llvm/
  17. llvm-libgcc/
  18. mlir/
  19. openmp/
  20. polly/
  21. pstl/
  22. runtimes/
  23. third-party/
  24. utils/
  25. .arcconfig
  26. .arclint
  27. .clang-format
  28. .clang-tidy
  29. .git-blame-ignore-revs
  30. .gitignore
  31. .mailmap
  32. CONTRIBUTING.md
  33. LICENSE.TXT
  34. README.md
  35. SECURITY.md
README.md

The LLVM Compiler Infrastructure

This directory and its sub-directories contain the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.

The README briefly describes how to get started with building LLVM. For more information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.

Getting Started with the LLVM System

Taken from here.

Overview

Welcome to the LLVM project!

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. It also contains basic regression tests.

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.

Getting the Source Code and Building LLVM

The LLVM Getting Started documentation may be out of date. The Clang Getting Started page might have more accurate information.

This is an example work-flow and configuration to get and build the LLVM source:

  1. Checkout LLVM (including related sub-projects like Clang):

    • git clone https://github.com/llvm/llvm-project.git

    • Or, on windows, git clone --config core.autocrlf=false https://github.com/llvm/llvm-project.git

  2. Configure and build LLVM and Clang:

    • cd llvm-project

    • cmake -S llvm -B build -G <generator> [options]

      Some common build system generators are:

      • Ninja --- for generating Ninja build files. Most llvm developers use Ninja.
      • Unix Makefiles --- for generating make-compatible parallel makefiles.
      • Visual Studio --- for generating Visual Studio projects and solutions.
      • Xcode --- for generating Xcode projects.

      Some common options:

      • -DLLVM_ENABLE_PROJECTS='...' and -DLLVM_ENABLE_RUNTIMES='...' --- semicolon-separated list of the LLVM sub-projects and runtimes you'd like to additionally build. LLVM_ENABLE_PROJECTS can include any of: clang, clang-tools-extra, cross-project-tests, flang, libc, libclc, lld, lldb, mlir, openmp, polly, or pstl. LLVM_ENABLE_RUNTIMES can include any of libcxx, libcxxabi, libunwind, compiler-rt, libc or openmp. Some runtime projects can be specified either in LLVM_ENABLE_PROJECTS or in LLVM_ENABLE_RUNTIMES.

        For example, to build LLVM, Clang, libcxx, and libcxxabi, use -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi".

      • -DCMAKE_INSTALL_PREFIX=directory --- Specify for directory the full path name of where you want the LLVM tools and libraries to be installed (default /usr/local). Be careful if you install runtime libraries: if your system uses those provided by LLVM (like libc++ or libc++abi), you must not overwrite your system's copy of those libraries, since that could render your system unusable. In general, using something like /usr is not advised, but /usr/local is fine.

      • -DCMAKE_BUILD_TYPE=type --- Valid options for type are Debug, Release, RelWithDebInfo, and MinSizeRel. Default is Debug.

      • -DLLVM_ENABLE_ASSERTIONS=On --- Compile with assertion checks enabled (default is Yes for Debug builds, No for all other build types).

    • cmake --build build [-- [options] <target>] or your build system specified above directly.

      • The default target (i.e. ninja or make) will build all of LLVM.

      • The check-all target (i.e. ninja check-all) will run the regression tests to ensure everything is in working order.

      • CMake will generate targets for each tool and library, and most LLVM sub-projects generate their own check-<project> target.

      • Running a serial build will be slow. To improve speed, try running a parallel build. That's done by default in Ninja; for make, use the option -j NNN, where NNN is the number of parallel jobs to run. In most cases, you get the best performance if you specify the number of CPU threads you have. On some Unix systems, you can specify this with -j$(nproc).

    • For more information see CMake.

Consult the Getting Started with LLVM page for detailed information on configuring and compiling LLVM. You can visit Directory Layout to learn about the layout of the source code tree.

Getting in touch

Join LLVM Discourse forums, discord chat or #llvm IRC channel on OFTC.

The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.