linux-kernel - Re: [LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix

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]

Message-ID: <CA+55aFy=w6v9MqcVn1H6X7jqJq+QrEx7TfA6Kr+vC4SYJRjUyQ@mail.gmail.com>
Date:	Mon, 15 Jul 2013 11:56:21 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Tim Northover <t.p.northover@...il.com>,
	Ramkumar Ramachandra <artagnon@...il.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Andi Kleen <ak@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	LLVMdev <llvmdev@...uiuc.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix

On Mon, Jul 15, 2013 at 11:40 AM, H. Peter Anvin <hpa@...or.com> wrote:
> On 07/14/2013 12:49 PM, Linus Torvalds wrote:
>
> This is also why the Intel manuals point out that "some assemblers" can
> take things like:
>
>         bt[l] $63,(%rsi)
>
> ... and turn it into:
>
>         btl $31,4(%rsi)
>
> This is definitely the friendly thing to do toward the human programmer.
>  Unfortunately gas doesn't, nor does e.g. NASM.

Yeah, that's definitely a "quality of implementation" issue. Clearly
"bt $63,mem" is talking about bit 63, and a quality assembler would
either warn about it or just do the RightThing(tm) like the intel
manual says.

I'd actually like to say "think you" to the gas people, because gas
today may not do the above, but gas today is still *lightyears* ahead
of where it used to be two decades ago. Back in those dark ages, GNU
as was even documented to be *only* about turning compiler output into
object code, and gas was the ghastliest assembler on the planet - it
silently did horrible horrible things, and didn't do *anything*
user-friendly or clever. It would entirely ignore things like implied
sizes from register names etc, and generate code that was obviously
not at all what the user expected, but because cc1 always used
explicit sizes etc and only generated very specific syntax, it "wasn't
an issue".

gas has improved immensely in this regard, and the fact that it
silently takes a $63 and effectively turns it into $31 is something I
think is not nice and not a good QoI, but considering where gas came
from, I'm not going to complain about it too much. It's
"understandable", even if it isn't great.

But quite frankly, partly because of just how bad gas used to be wrt
issues like this, I think that any other assembler should aim to be at
_least_ as good as gas, if not better. Because I definitely don't want
to go back to the bad old days. I've been there, done that. Assemblers
that are worse than gas are not worth working with. gas should be
considered the minimal implementation quality, and llvm-as should
strive to do better rather than worse..

(NASM used to be *much* more pleasant to work with than gas. Maybe you
should strive to make nasm DTRT wrt bt and constants, and maintain
that lead?)

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