[LLVMbugs] [Bug 18303] New: Code emitted in wrong CPU mode after fixup relaxation.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=18303

            Bug ID: 18303
           Summary: Code emitted in wrong CPU mode after fixup relaxation.
           Product: libraries
           Version: 3.3
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: dwmw2 at infradead.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ cat foo64.S
.global edata
sub $edata, %r12
$ clang  -o foo64.o -c foo64.S && objdump -d foo64.o | tail -2
0000000000000000 <.text>:
   0:    49 81 ec 00 00 00 00     sub    $0x0,%r12

 (correct)

$ echo '.code32' >> foo64.S ; cat foo64.S
.global edata
sub $edata, %r12
.code32
$ clang  -o foo64.o -c foo64.S && objdump -d foo64.o | tail -2
0000000000000000 <.text>:
   0:    81 ec 00 00 00 00        sub    $0x0,%esp


This happens because the code emitter is taking its idea of whether it's in
32-bit or 64-bit mode directly from the Subtargetinfo, which is manipulated
only by the AsmParser as it processes the source file.

So when we do relaxations, *all* the relaxed instructions are processed by the
code emitted in whatever mode the AsmParser happened to end up in at the very
end of the file.

I see two possible approaches to fixing this. One is to store the mode changes
in fragments as we go along, and play them back as we're processing the
fragments — so that the relaxed instructions are encoded in the correct mode.
Except I can't see how to get the mode switches to the CodeEmitter object. The
AsmBackend has a handleAssemblerFlag() method to do it (which X86 doesn't even
implement, although ARM does) — but there's no way for the CodeEmitter to get
it from there, AFAICT. Even on ARM the CodeEmitter is just looking at the
SubtargetInfo. A start at this approach is shown at
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199633.html

The other approach is to store the current CPU mode (or perhaps it should be
the full set of feature flags) in the MCInst as it's created. Horrid dirty (but
working) proof of concept at
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199637.html
(along with a discussion of why I abandoned the first approach; summarised
above).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131221/bac7d3ac/attachment.html>