]>
Commit | Line | Data |
---|---|---|
e18652ec | 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 | ||
81a55c72 | 5 | * Checkout recent GCC tree. |
3ae7a7a7 | 6 | * Run merge.sh script from libsanitizer directory. The script accepts one |
7 | argument that is control version system (svn or git). | |
81a55c72 | 8 | * Modify Makefile.am files into asan/tsan/lsan/ubsan/sanitizer_common/interception |
e18652ec | 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 | |
81a55c72 | 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 | |
0a875e25 | 15 | them might be already included to upstream). The list of these patches is stored |
16 | into LOCAL_PATCHES file. | |
81a55c72 | 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 | |
3ae7a7a7 | 24 | library for sanitizer libs). |
81a55c72 | 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. | |
3ae7a7a7 | 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*). | |
81a55c72 | 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). | |
0a875e25 | 44 | * Update LOCAL_PATCHES file when you've committed the whole patch set with new revisions numbers. |