[PATCH v2] X86: disambiguate unqualified btr, bts

[Jim Grosbach]

On Jul 13, 2013, at 2:10 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:

> PaX Team wrote:
>> http://llvm.org/bugs/show_bug.cgi?id=9362
>> 
>> and the conclusion was to change the linux (user) side, not llvm.
> 
> I'm not understanding this: what is so special about btr/bts, and why
> is the solution I'm proposing any different from 824a907 (which was
> written a month before this bug was classified as WONTFIX), which
> disambiguates bt as btl?  If llvm's policy is to reject all ambiguous
> instructions, then 824a907 (and possibly other commits) must be
> reverted for a consistency.
> 
> What is the problem with matching gas behavior?  Is there some insane
> unpredictable magic going on in gas (can you give me inputs to
> demonstrate this)?  If the instructions really are Wrong, why hasn't
> linux.git been patched yet?  Can you write me a coherent explanation
> as to why it is Wrong to support perfectly valid instruction
> mnemonics, and how linux.git should be patched, in that case?

You are presupposing gas to be some magical thing that by definition determines proper behavior for other tools. That’s crap. The same holds true for them the other direction when looking at our (or any other) assembler. If adding aliases for these mnemonics is the right thing to do, then an argument can and should be made for that independent of gas’ current behavior. It’s entirely possible gas is doing the right thing here and LLVM should do that same thing. It’s entirely possible gas is doing something wrong and should be fixed instead. Taking either position a priori is pointless and counterproductive.

There’s a lot of really good information in this thread and it’s companion LKML thread, and there’s references to other sources for more background context than one can shake a stick at. With some digging, there’s probably enough there to generate a very solid proposal to LLVM and/or Linux for whatever changes are appropriate.

-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130715/86718fca/attachment.html>