[PATCH v2 0/14] [x86] Fix 16-bit addressing modes (PR18220) and implement .code16 (PR8684)

David Woodhouse dwmw2 at infradead.org
Fri Dec 20 13:16:57 PST 2013

Hm, I have found a very strange bug...

$ cat foo.S
.globl edata
subl $edata, %ecx
$ Debug+Asserts/bin/llvm-mc -triple i386-unknown-unknown --show-encoding foo.S
	.globl	edata
	subl	$edata, %ecx            # encoding: [0x83,0xe9,A]
                                        #   fixup A - offset: 2, value: edata, kind: FK_Data_1
$ ../llvm-svn/Debug+Asserts/bin/clang -c -m32 -o foo.o foo.S ; objdump -d foo.o  | grep sub
   0:	81 e9 00 00 00 00    	sub    $0x0,%ecx

OK... that's not what it said it would do, but OK. It must be something
to do with attempting to use FK_Data_1 for what turned out to be a
R_386_32 relocation, and later fixing it up. But...

$ echo ".code16" >> foo.S
$ ../llvm-svn/Debug+Asserts/bin/clang -c -m32 -o foo.o foo.S ; objdump -d foo.o  | grep sub
   0:	66 81 e9 00 00       	sub    $0x0,%cx

I'm guessing the relocation fixups are happening after the .code16
switch has been processed? How does this work?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131220/bbe6c024/attachment.bin>

More information about the llvm-commits mailing list