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