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.
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.
Jakub
