This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Backporting KAsan patches to 4.9 branch
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Dmitry Vyukov <dvyukov at google dot com>, Konstantin Khlebnikov <k dot khlebnikov at samsung dot com>, Andrey Ryabinin <a dot ryabinin at samsung dot com>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>
- Date: Tue, 14 Oct 2014 13:14:09 +0200
- Subject: Re: Backporting KAsan patches to 4.9 branch
- Authentication-results: sourceware.org; auth=none
- References: <541AA9ED dot 6040705 at samsung dot com> <20140918095754 dot GC17454 at tucnak dot redhat dot com> <543D03FE dot 1020204 at samsung dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Oct 14, 2014 at 03:07:42PM +0400, Yury Gribov wrote:
> Finally got time to look into this. I've successfully backported 22 patches
> to 4.9:
> * bugfixes (12 patches)
> * install Asan headers (1 patch)
> * libsanitizer merge (1 patch) - this is questionable, see below for
> discussion
> * BUILT_IN_ASAN_REPORT_{LOAD,STORE}_N (2 patches)
> * instrumentation with calls (1 patch)
> * optimize strlen instrumentation (1 patch)
> * move inlining to sanopt pass (2 patches)
> * Kasan (2 patches)
>
> One problem is that for BUILT_IN_ASAN_REPORT_{LOAD,STORE}_N patch I need
> libsanitizer APIs (__asan_loadN, __asan_storeN) which were introduced in a
> giant libsanitizer merge in 5.0. In current patchset I backport the whole
> merge patch (and a bunch of cherry-picks which followed it) but it changes
> libsanitizer ABI (new version of __asan_init_vXXX, etc.) which is probably
> undesirable. Another option would be to backport just the necessary minimum
> (__asan_loadN, __asan_storeN). How should I proceed?
Yeah, such library changes are definitely not acceptable for 4.9 branch.
So, can you throw away all the patches which depend on the new libsanitizer
entry points? If you need those for KAsan which doesn't need the library
(right?), then tweak the patches so that the new functions are used in
-fsanitize=kernel-address mode only, and never in 4.9 for -fsanitize=address
-?
> Another question: Should I update patch CL dates for backported patches? If
> not - should I insert them to CLs in chronological order or just stack on
> top of previous contents?
Usually, if you backport patches (not the same committer or committed
on later date to branch from the commit date to trunk), one writes
2014-xx-yy You <you@where.com>
Backported from mainline
2014-zz-nn Somebody <somebody@somewhe.re>
...
See branch ChangeLog for examples.
Jakub