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: Yury Gribov <y dot gribov at samsung dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, 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>, 'Marat Zakirov' <marat61 at gmail dot com>
- Date: Thu, 29 May 2014 17:04:10 +0400
- Subject: Re: [PATCH] Inline asm asan instrumentation
- Authentication-results: sourceware.org; auth=none
- References: <000001cf7a79$745ee000$5d1ca000$ at samsung dot com> <20140529100832 dot GQ10386 at tucnak dot redhat dot com>
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.
Do we have precise semantics of "m" written somewhere?
My understanding was that even though asm may not touch buffer at all
(like e.g. in our tests),
user still declares whole region accessible to compiler.
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.
We've seen this abused (e.g. casting to struct { char x[0xffffffff]; } *)
and that's main reason why we turned this off by default.
On the other we've seen no problems with ffmpeg's testsuite
and ability to detect overflows in inline asm would be rather useful.
Do you see how we could make this more robustly?
We could e.g. only check the first byte
although this wouldn't be as useful.
-Y