The label calculation is not correct in the following simple ARM asm .text .syntax unified .code 32 .type DATA,%object .align 5 DATA: .word 0x428a2f98,0x71374491,0xb5c0fbcf,0xe9b5dba5 .word 0x3956c25b,0x59f111f1,0x923f82a4,0xab1c5ed5 .word 0xd807aa98,0x12835b01,0x243185be,0x550c7dc3 .word 0x72be5d74,0x80deb1fe,0x9bdc06a7,0xc19bf174 .word 0xe49b69c1,0xefbe4786,0x0fc19dc6,0x240ca1cc .word 0x2de92c6f,0x4a7484aa,0x5cb0a9dc,0x76f988da .word 0x983e5152,0xa831c66d,0xb00327c8,0xbf597fc7 .word 0xc6e00bf3,0xd5a79147,0x06ca6351,0x14292967 .word 0x27b70a85,0x2e1b2138,0x4d2c6dfc,0x53380d13 .word 0x650a7354,0x766a0abb,0x81c2c92e,0x92722c85 .word 0xa2bfe8a1,0xa81a664b,0xc24b8b70,0xc76c51a3 .word 0xd192e819,0xd6990624,0xf40e3585,0x106aa070 .word 0x19a4c116,0x1e376c08,0x2748774c,0x34b0bcb5 .word 0x391c0cb3,0x4ed8aa4a,0x5b9cca4f,0x682e6ff3 .word 0x748f82ee,0x78a5636f,0x84c87814,0x8cc70208 .word 0x90befffa,0xa4506ceb,0xbef9a3f7,0xc67178f2 .word 0x90befffa,0xa4506ceb,0xbef9a3f7,0xc67178f2 .word 0x90befffa,0xa4506ceb,0xbef9a3f7,0xc67178f2 .word 0x90befffa,0xa4506ceb,0xbef9a3f7,0xc67178f2 .word 0x90befffa,0xa4506ceb,0xbef9a3f7,0xc67178f2 .word 0x90befffa,0xa4506ceb,0x90befffa,0xa4506ceb .size DATA,.-DATA .word 0 @ terminator .global FOO .type FOO,%function .align 5 FOO: .L1: adr r3,.L1 sub r3, r3, #(.L1-DATA) @ Now r3 should point to start of DATA (0) .size FOO,.-FOO This is what I get from gnu-as- 00000160 <FOO>: 160: e24f3008 sub r3, pc, #8 ; Now r3 is 0x160 164: e2433e16 sub r3, r3, #352 ; 0x160 The 2 subs results 0 (which is the correct starting address) in r3 Now this is what I get from clang - 00000160 <FOO>: 160: e24f3008 sub r3, pc, #8 ; Now r3 is 0x160 164: e2433160 sub r3, r3, #96, 2 ; After this r3 is not zero The 2 subs results in a different value than the start address of DATA. (The relocation section of the object file is empty)
Looks like a problem with instruction format: 352 = 0x160 = (2 >> 1) << 8 | 96 = encoding of arm operand 2 #96, 2 llvm-mc -show-inst seems to have a similar problem: 3606 = 0xe16 = (28 >> 1) << 8 | 22 = encoding of arm operand 2 #22, 28 (which is 352) sub r5, r5, #352 @ <MCInst #468 SUBri @ <MCOperand Reg:71> @ <MCOperand Reg:71> @ <MCOperand Imm:3606> @ <MCOperand Imm:14> @ <MCOperand Reg:0> @ <MCOperand Reg:0>> sub r5, r5, #96, #2 @ <MCInst #468 SUBri @ <MCOperand Reg:71> @ <MCOperand Reg:71> @ <MCOperand Imm:352> @ <MCOperand Imm:14> @ <MCOperand Reg:0> @ <MCOperand Reg:0>>
The labels or expressions in the last operand of subs are matched by ModImm, which gets an FK_Data_4 fixup that patches the 12 LSBs of the instruction directly after the offsets of the labels or the value of the expressions are decided.
getModImmOpValue() emits FK_Data_4 which patches the lowest 12 bits of instructions by the value bit-to-bit. This is incompatible with the modified-immediate encoding. The proposed solution is to make a new fixup kind: fixup_arm_mod_imm which takes care of the encoding. http://reviews.llvm.org/D15442
Verified patch in comment 3), with the patch, we are now finally able to bring up ARM ChromeOS built with clang.