Skip to content
  1. Jul 05, 2012
  2. Jul 03, 2012
  3. Jul 02, 2012
  4. Jun 29, 2012
  5. Jun 27, 2012
  6. Jun 26, 2012
  7. Jun 25, 2012
    • Dmitry Vyukov's avatar
      tsan: remove internal allocator, switch to sanitizer_common one. · c598de93
      Dmitry Vyukov authored
      llvm-svn: 159142
      c598de93
    • Kostya Serebryany's avatar
      [tsan] lint · aad697eb
      Kostya Serebryany authored
      llvm-svn: 159140
      aad697eb
    • Kostya Serebryany's avatar
      [tsan] minor changes in tsan allocator · 100590f7
      Kostya Serebryany authored
      llvm-svn: 159139
      100590f7
    • Kostya Serebryany's avatar
      [tsan] fix the build · 6bbb5140
      Kostya Serebryany authored
      llvm-svn: 159137
      6bbb5140
    • Chandler Carruth's avatar
      Cleanup the handling of CFLAGS even more in the cmake build for ASan. · 9359efa9
      Chandler Carruth authored
      Add the initial support for building ASan tests.
      
      The first change here is to try to get the CFLAGS to more closely match
      those used by the old Makefile. There are probably still goofs here,
      ASan folks, your review would be appreciated.
      
      The second big change is to add support for building both
      instrumentation based an non-instrumentation based unittests for ASan.
      They are built a bit differently from how the old makefiles managed
      things. Specifically, there are two binaries, one for the
      non-instrumented case, and one for the instrumented case.
      
      Also, the instrumented unit tests rely on the host compiler supporting
      AddressSanitizer's intrumentation pass. This is kind-of gross, but
      I don't know of a better way yet. I've mailed llvmdev to discuss this
      issue.
      
      One big caveat is that the detection logic currently doesn't work. I've
      commented it out temporarily as I'd like to get feedback from the ASan
      developers, etc.
      
      llvm-svn: 159134
      9359efa9
    • Chandler Carruth's avatar
      Another big step toward a viable CMake build system for CompilerRT, · c78ad00c
      Chandler Carruth authored
      ASan, and friends.
      
      This explicitly switches the CompilerRT CMake build to require CMake
      version 2.8.8 or newer which provides first-class support for "object"
      libraries which consist of a pile of '.o' files -- exactly what is
      desired for composing runtime libraries. I've gone ahead and switched to
      using this.
      
      I've also added the interception library which I missed initially. And
      I've added proper dependencies between the various libraries. With this,
      I'm able to build archives for asan that appear to contain all of the
      necessary .o files.
      
      The final tweak here is to start setting up the compile flags and macro
      defines expected by ASan and its helper libraries. These may not be
      entirely correct currently, they're based loosely on my reading of the
      old Makefiles. However, they can be tweaked more easily now that they're
      wired up properly.
      
      llvm-svn: 159129
      c78ad00c
    • Kostya Serebryany's avatar
      [tsan] a better CHECK for OOM in the new allocator · f299f701
      Kostya Serebryany authored
      llvm-svn: 159122
      f299f701
  8. Jun 22, 2012
  9. Jun 21, 2012
  10. Jun 20, 2012
    • Kostya Serebryany's avatar
    • Chandler Carruth's avatar
      Resuming work on the compiler-rt CMake build at long long last. In order · bf22bd21
      Chandler Carruth authored
      to get it working again, two changes were needed:
      
      - I had to give up on glob-based file expansion. This just isn't well
        supported by CMake, and until we convince upstream there of its value,
        it's not worth dealing with the pain.
      - Add the common library as otherwise even ASan won't build.
      
      This now builds again, although the "correctness" of it is a touch
      debatable. ;] Specifically, there is no merging of the common runtime
      library with the asan runtime library into a single archive file. I'm
      not really sure what the best technique is for that, and it may be
      influenced by the ongoing discussion about how best to link runtime
      libraries.
      
      Note of course that this is still very much WIP. It doesn't entirely
      work yet, and remains disabled by the LLVM projects/CMakeLists.txt until
      it is in a working state.
      
      llvm-svn: 158811
      bf22bd21
  11. Jun 19, 2012
  12. Jun 18, 2012
  13. Jun 15, 2012
Loading