[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] linux/x86: avoid casting hypercallarguments to long


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Mon, 21 Jan 2008 17:18:42 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 21 Jan 2008 09:18:56 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AchcUauI6eA5XshEEdyRYQAWy6hiGQ==
  • Thread-topic: [Xen-devel] [PATCH] linux/x86: avoid casting hypercallarguments to long

On 21/1/08 16:42, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 21.01.08 17:27 >>>
>> On 21/1/08 15:18, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>> 
> In its type: This way, the type gets promoted to int for anything smaller
> than int, but left alone if long (or wider) or pointer. Various gcc versions
> appear to have various problems when not promoting to at least int...

It's not really clear that passing an int to 64-bit inline asm guarantees
that the upper 32 bits of the 64-bit register are zero, is it? If you pass a
32-bit value to inline asm then gcc emits 32-bit register operands. I'll
admit it's very *likely* that the value will turn out to be zero-extended,
if you go at the argument with an explicit 64-bit access, because of x86_64
register write semantics, but not clear it's guaranteed.

>> Is it guaranteed that gcc will keep the register variables in their assigned
>> registers across the inline asm?
> 
> That's how they document it, so I suppose this is the canonical way
> and can be expected to not break.

Is it documented in the 'info gcc' documentation somewhere?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.