This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Add asm constraint modifier to mark strict memory accesses
- From: Dmitry Vyukov <dvyukov at google dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Marat Zakirov <m dot zakirov at samsung dot com>, Andrey Ryabinin <a dot ryabinin at samsung dot com>, Konstantin Khlebnikov <k dot khlebnikov at samsung dot com>
- Date: Fri, 19 Sep 2014 11:50:24 -0700
- Subject: Re: [RFC] Add asm constraint modifier to mark strict memory accesses
- Authentication-results: sourceware.org; auth=none
- References: <541ABD6E dot 3030904 at samsung dot com> <CACT4Y+ZUXJXVQfVxZ2w0RhNGoO9S4qPorV2n7rATOG2v4HBT9Q at mail dot gmail dot com> <541BC25B dot 50000 at samsung dot com>
On Thu, Sep 18, 2014 at 10:42 PM, Yury Gribov <firstname.lastname@example.org> wrote:
> On 09/18/2014 09:33 PM, Dmitry Vyukov wrote:
>> What is the number of cases it will fix for kasan?
> Re-added kernel people again.
> AFAIR silly instrumentation that assumed all memory accesses in inline asm
> are must-accesses (instead of may-accesses) resulted in only one false
> positive. We haven't performed an extensive testing though.
>> It won't fix the memchr function because the size is indeed not known
>> statically. So it's a bad example.
> Sure, we will _not_ be able to instrument memchr. But being able to identify
> "safe" inline asms would allow us to instrument those (and my gut feeling is
> that they are a vast majority).
>> My impression was that kernel has relatively small amount of assembly,
> $ grep -r '"[=+]\?[moVv<>]" *(' ~/src/linux-stable/ | wc -l
> And also
> $ grep -r '"[=+]\?[moVv<>]" *(' ~/src/ffmpeg-2.2.2/ | wc -l
>> And the rest is just not interesting enough.
> Now that may be the case. But how do we know without trying?
Well, we can look at some instances at least before committing new code to gcc.
Here are results of your grep with removed "prefetch" and removed
archs except x86:
It seems that it is mostly synchronization primitives and raid6
driver. Boot and s390 drivers are probably not very interesting.
Synchronization primitives are definitely interesting for asan
(because of racy use-after-free's). The rest looks very mildly
I do not see a very strong need for doing this for asan. There can be
other reasons, of course.