https://sourceware.org/bugzilla/show_bug.cgi?id=17712
--- Comment #1 from Michael Rolle <m at rolle dot name> --- Actually, it's worse than that. Look at the actual code bytes assembled. Disassembly of section .text: 0000000000000000 <.text>: 0: ff d0 call rax 2: ff d0 call rax 4: 66 ff d0 call ax 7: 66 ff d0 call ax a: 66 ff 10 call WORD PTR [rax] d: ff e0 jmp rax f: ff e0 jmp rax 11: 66 ff e0 jmp ax 14: 66 ff e0 jmp ax 17: 66 ff 20 jmp WORD PTR [rax] 1a: e8 5b 00 10 00 call 10007a <.text+0x10007a> 1f: e9 60 00 10 00 jmp 100084 <.text+0x100084> 24: ff d0 call rax 26: ff d0 call rax 28: 66 ff d0 call ax 2b: 66 ff d0 call ax 2e: 66 ff 10 call WORD PTR [rax] 31: ff e0 jmp rax 33: ff e0 jmp rax 35: 66 ff e0 jmp ax 38: 66 ff e0 jmp ax 3b: 66 ff 20 jmp WORD PTR [rax] 3e: e8 7f 00 10 00 call 1000c2 <.text+0x1000c2> 43: e9 84 00 10 00 jmp 1000cc <.text+0x1000cc> Each of the four call and jump instructions has an address of 0x100040 in the source code. The displacement in the first instruction, at 1a, is 10005b, so without relocation, the instruction will call/jump to address 10005b + (RIP = 1f) = 10007a, and this is relative to the .text segment. Actually, I believe that it is not possible in 64-bit mode to jump to an absolute address with a displacement, at least on Windows, because the loader would not have instructions in the image file to perform the relocation at image load time. As I recall, the only way to do it is to load the address into a register and then call/jump with the register as the operand. Hence, as should probably be giving an error message for 'jmp 0x100040', at least on Windows. Maybe unix/linux can make it work, I don't know. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
