On 09/18/2014 03:16 PM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 03:09:34PM +0400, Yury Gribov wrote:
Current semantics of memory constraints in GCC inline asm (i.e. "m", "v",
etc.) is somewhat loosy in that it tells GCC that asm code _may_ access
given amount of bytes but is not guaranteed to do so. This is (ab)used by
e.g. glibc (and also some pieces of kernel):
__STRING_INLINE void *
__rawmemchr (const void *__s, int __c)
{
...
__asm__ __volatile__
("cld\n\t"
"repne; scasb\n\t"
...
"m" ( *(struct { char __x[0xfffffff]; } *)__s)
Imprecise size specification prevents code analysis tools from understanding
semantics of inline asm (without parsing inline asm instructions which e.g.
Asan in Clang tries to do). In particular we can't automatically instrument
inline asm in kernel with Kasan because we can not determine exact access
size (see e.g. discussion in
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02530.html).
Would it make sense to add another constraint modifier (like "=", "&", etc.)
that would tell compiler/tool that memory access in asm is _guaranteed_ to
have the specified size?
CCing Richard/Jeff on this for thoughts.
Would that modifier mean that the inline asm is unconditionally reading
resp. writing that memory? "m"/"=m" right now is always about might read or
might write, not must.
Yes, that's what I had in mind. Many inline asms (at least in kernel) do
read memory region unconditionally.
In any case, as no GCC versions support that, you'd need to heavily macroize
it in the kernel, not sure the kernel people would like that very much.
They said they could think about it.
-Y
