Home | History | Annotate | Line # | Download | only in libsanitizer 
      1  1.1  mrg In general, merging process should not be very difficult, but we need to
      2  1.1  mrg track various ABI changes and GCC-specific patches carefully.  Here is a
      3  1.1  mrg general list of actions required to perform the merge:
      4  1.1  mrg 
      5  1.1  mrg * Checkout recent GCC tree.
      6  1.5  mrg * Run merge.sh script from libsanitizer directory.
      7  1.1  mrg * Modify Makefile.am files into asan/tsan/lsan/ubsan/sanitizer_common/interception
      8  1.1  mrg   directories if needed.  In particular, you may need to add new source files
      9  1.1  mrg   and remove old ones in source files list, add new flags to {C, CXX}FLAGS if
     10  1.1  mrg   needed and update DEFS with new defined variables.  You can find these changes
     11  1.1  mrg   in corresponding CMakeLists.txt and config-ix.cmake files from compiler-rt source
     12  1.1  mrg   directory.
     13  1.1  mrg * Apply all needed GCC-specific patches to libsanitizer (note that some of
     14  1.3  mrg   them might be already included to upstream).  The list of these patches is stored
     15  1.3  mrg   into LOCAL_PATCHES file.
     16  1.1  mrg * Apply all necessary compiler changes.  Be especially careful here, you must
     17  1.1  mrg   not break ABI between compiler and library.  You can reveal these changes by
     18  1.1  mrg   inspecting the history of AddressSanitizer.cpp and ThreadSanitizer.cpp files
     19  1.1  mrg   from LLVM source tree.
     20  1.1  mrg * Update ASan testsuite with corresponding tests from lib/asan/tests directory.
     21  1.1  mrg   Not all tests can be migrated easily, so you don't need them all to be adapted.
     22  1.1  mrg * Modify configure.ac file if needed (e.g. if you need to add link against new
     23  1.4  mrg   library for sanitizer libs).
     24  1.1  mrg * Add new target platforms in configure.tgt script if needed.
     25  1.1  mrg * Bump SONAME for sanitizer libraries in asan/tsan/ubsan libtool-version files
     26  1.1  mrg   if ABI has changed.
     27  1.1  mrg * Regenerate configure script and all Makefiles by autoreconf.  You should use
     28  1.1  mrg   exactly the same autoconf and automake versions as for other GCC directories (current
     29  1.1  mrg   versions are written in Makefile.in and configure files).
     30  1.1  mrg * Run regression testing on at least three platforms (e.g. x86-linux-gnu, x86_64-linux-gnu,
     31  1.1  mrg   aarch64-linux-gnu, arm-linux-gnueabi).
     32  1.1  mrg * Run {A, UB}San bootstrap on at least three platforms.
     33  1.4  mrg * Compare ABI of corresponding libclang_rt.asan and newly build libasan libraries.
     34  1.4  mrg   Similarly you can compare latest GCC release with the newly built libraries
     35  1.4  mrg   (libasan.so.*, libubsan.so.*, libtsan.so*).
     36  1.1  mrg   You can use a pretty good libabigail tool (https://sourceware.org/libabigail/index.html)
     37  1.1  mrg   to perform such a comparision.  Note, that the list of exported symbols may differ,
     38  1.1  mrg   e.g. because libasan currently does not include UBSan runtime.
     39  1.1  mrg * Split your changes into logical parts (e.g. raw merge, compiler changes, GCC-specific changes
     40  1.1  mrg   in libasan, configure/Makefile changes). The review process has O(N^2) complexity, so you
     41  1.1  mrg   would simplify and probably speed up the review process by doing this.
     42  1.1  mrg * Send your patches for review to GCC Patches Mailing List (gcc-patches (a] gcc.gnu.org).
     43  1.3  mrg * Update LOCAL_PATCHES file when you've committed the whole patch set with new revisions numbers.
     44