This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] x86 string/memory inline functions

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] x86 string/memory inline functions
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 24 May 2006 10:55:22 +0200
Delivery-date: Wed, 24 May 2006 01:54:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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