<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Code emitted in wrong CPU mode after fixup relaxation."
href="http://llvm.org/bugs/show_bug.cgi?id=18303">18303</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Code emitted in wrong CPU mode after fixup relaxation.
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>3.3
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>MC
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>dwmw2@infradead.org
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>$ 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
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199633.html">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199633.html</a>
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
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199637.html">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199637.html</a>
(along with a discussion of why I abandoned the first approach; summarised
above).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>