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:	Sat, 24 Jan 2009 11:23:18 -0800
From:	Chris Lattner <clattner@...le.com>
To:	LLVM Developers Mailing List <llvmdev@...uiuc.edu>
Cc:	Török Edwin <edwintorok@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [LLVMdev] inline asm semantics: output constraint width smaller than	input

On Jan 24, 2009, at 9:27 AM, Ingo Molnar wrote:

>> #define __put_user_size(x, ptr, size, retval, errret)            \
>> diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c
>> index f456860..12d27f8 100644
>> --- a/arch/x86/lib/delay.c
>> +++ b/arch/x86/lib/delay.c
>> @@ -112,7 +112,7 @@ EXPORT_SYMBOL(__delay);
>>
>> inline void __const_udelay(unsigned long xloops)
>> {
>> -    int d0;
>> +    unsigned long d0;
>>
>>     xloops *= 4;
>>     asm("mull %%edx"
>
> Is this all that you need (plus the 16-bit setup code tweaks) to get  
> LLVM
> to successfully build a 64-bit kernel image?
>
> 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.

Hi Ingo,

We would like to support some more specific cases (e.g. when tying a  
pointer/int to a different size pointer/int) but we currently don't  
intend to support all cases (e.g. tying a FP value to int).  We are in  
this position because the semantics are very vague and hard to reason  
about (and change based on target endianness) and we had many subtle  
bugs in the corner cases.

Instead of having silent miscompiles, we decided to just reject all  
the "hard" cases and add them back one by one as there is demand.   
That way users could choose to modify their asms instead of having  
them be potentially silently miscompiled.

LLVM 2.5 is in its release process right now, so it will not have  
improvements in this area, but LLVM 2.6 certainly could.  If there is  
interest in building the kernel with 2.5, I think taking the patches  
would be worthwhile.  If that is hopeless anyway, waiting for the LLVM- 
side fixes should be fine.

-Chris
--
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/