linux-kernel - Re: [LLVMdev] inline asm semantics: output constraint width smaller than input

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Jan 2009 13:25:18 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Duncan Sands <baldrick@...e.fr>
CC:	llvmdev@...uiuc.edu, Ingo Molnar <mingo@...e.hu>,
	Török Edwin 
	<edwintorok@...il.com>, Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [LLVMdev] inline asm semantics: output constraint width smaller
  than input

Duncan Sands wrote:
> Hi,
> 
>> If yes then this doesnt look all that bad or invasive at first sight (if 
>> the put_user() workaround can be expressed in a cleaner way), but in any 
>> case it would be nice to hear an LLVM person's opinion about roughly when 
>> this is going to be solved in LLVM itself.
> 
> one thing that seems to be clear to everyone except me is... what are the
> semantics supposed to be?  [My understanding is that what is being discussed
> is when you have an asm with a register as input and output, but with integer
> types of different width for the input and output, but I saw some mention of
> struct types in this thread...].  Presumably this is something obvious, but
> it would be good to have someone spell it out in small words that even someone
> like me can understand :)
> 

I don't know about struct types, but the situation I'm talking about is 
assembly statements of the form:

asm("foo" : "=r" (bar) : "0" (baz));

Here, "bar" and "baz" are constrained to be in the same hardware 
register (from the "0" constraint in "baz").  The types of "bar" and 
"baz" are otherwise unrelated.

I assume the difficulty here comes from how this needs to be handled 
from the point of view of the register allocator.  If both types fit 
inside a single allocatable hardware register, the issue is trivial; 
"bar" and "baz" form a single logical register for the purpose of 
register allocation.

However, things get a bit ugly in the case of different widths that 
affect individually scheduled registers, like 32- and 64-bit types on a 
32-bit machine.  Consider the case above where "bar" is a 64-bit type 
and "baz" is a 32-bit type, then you functionally have, at least on x86:

	uint64_t tmp = bar;
	asm("foo" : "+r" (tmp));
	baz = (uint32_t)tmp;

One could possibly argue that the latter case should be
"baz = (uint32_t)(tmp >> 32);" on a bigendian machine... since this is a 
gcc syntax it probably should be "whatever gcc does" in that case, as 
opposed to what might make sense.

(I'm afraid I don't have a bigendian box readily available at the 
moment, so I can't test it out to see what gcc does.  I have a powerpc 
machine, but it's at home and turned off.)

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/