This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Inline asm asan instrumentation
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Marat Zakirov <m dot zakirov at samsung dot com>
- Cc: gcc-patches at gcc dot gnu dot org, "'Konstantin Serebryany'" <kcc at gcc dot gnu dot org>, "'Viacheslav Garbuzov'" <v dot garbuzov at samsung dot com>, "'Yuri Gribov'" <y dot gribov at samsung dot com>, "'Marat Zakirov'" <marat61 at gmail dot com>
- Date: Thu, 29 May 2014 12:08:32 +0200
- Subject: Re: [PATCH] Inline asm asan instrumentation
- Authentication-results: sourceware.org; auth=none
- References: <000001cf7a79$745ee000$5d1ca000$ at samsung dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, May 28, 2014 at 05:33:44PM +0400, Marat Zakirov wrote:
> Here's a patch for optional Asan instrumentation of inline assembly.
>
> This version scans gimple for GIMPLE_ASMs and performs usual instrumentation
> of arguments with memory constraints ("m", "o", etc.) with fixed size.
That doesn't look right to me. The fact that some region appears in "m"
doesn't mean the inline asm actually accesses it, it could not touch it at
all, or only some part of it.
If you look e.g. at Linux kernel headers, you'll see lots of
struct __large_struct { unsigned long buf[100]; };
#define __m(x) (*(struct __large_struct __user *)(x))
...
"m" (__m(addr))
and similar cases, if Asan wants to check that the whole 100*sizeof(long)
region is accessible, it could often just have false positives, because the
inline asm really accesses just some small part of it.
Jakub