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