|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] x86 string/memory inline functions
Apparently, the contents of xen/include/asm-x86/string.h have been derived from
Linux i386 code, with a few adjustments
for x86-64, and with some memory clobbers removed from functions where the
memory is only read. That latter fact is what
I'm curious about: Without these clobbers (and without appropriate input
constraints added), how is the compiler
supposed to know that the memory pointed to by some of the other inputs is
being accessed?
I'm specifically running into a problem where I wanted to insert an extra
strcmp() in cmdline_parse() (in
xen/common/kernel.c) after the zero termination of the entire option and the
call to strchr() to determine whether the
option has a value specified. gcc 3.3.1 (SuSE version), which I'm using on one
of my build machines, reorders things so
the zero termination happens only after the newly added strcmp(), clearly
because it can't derive that strcmp() relies
on this very memory being up-to-date. Surprisingly, using 3.4.4 or 4.0.3
(gnu.org version) doesn't yield the same
problem, but I'm nevertheless convinced this is not a compiler bug in 3.3.1.
So there are basically two questions:
1) Why were the (questionable) inline versions from i386 Linux chosen over just
using the gcc intrinsics (as x86-64
Linux does, except for a special case of memcpy())?
2) Why were the memory clobbers removed without at least replacing them with
appropriate input constraints?
Thanks, Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] x86 string/memory inline functions,
Jan Beulich <=
|
|
|
|
|