search for: jmpq

...n is patched to jump to garbage. Breakpoint 1, 0x0000000100001c19 in main () (gdb) display/i $pc 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 <dyld_stub___cxa_throw> (gdb) si 0x0000000100016386 in dyld_stub___cxa_throw () 2: x/i $pc 0x100016386 <dyld_stub___cxa_throw>: jmpq *0xae1c(%rip) # 0x1000211a8 (gdb) 0x0000000102244870 in __cxa_throw () 2: x/i $pc 0x102244870 <__cxa_throw>: jmpq 0xffd27000 (gdb) # the above its __cxa_throw in gcc's libstdc++.6.dylib. The first instruction has been patch to jump to a garbage address. (gdb) x/8i 0x102244...

...mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c 0x00007f0de11c41fc: mov 0x8(%r10),%rax 0x00007f0de11c4200: incl (%rax) 0x00007f0de11c4202: mov (%r10),%rax 0x00007f0de11c4205: incl (%rax) 0x00007f0de11c4207: jmpq 0x7f0de11c41f0 0x00007f0de11c420c: xor %rax,%rax 0x00007f0de11c420f: retq I use init_trampoline to generate code that sets up the static link: 0x00007fffee982316: mov $0x7f48e1a08fb0,%r11 0x00007fffee982320: mov $0x7fffee982330,%r10 the static link 0x00007...

...0100000f16 in main () 1: x/i $pc 0x100000f16 <main+22>: mov $0x0,%al (gdb) 0x0000000100000f18 in main () 1: x/i $pc 0x100000f18 <main+24>: callq 0x100000f34 <dyld_stub_printf> (gdb) 0x0000000100000f34 in dyld_stub_printf () 1: x/i $pc 0x100000f34 <dyld_stub_printf>: jmpq *0x106(%rip) # 0x100001040 (gdb) 0x0000000100000f56 in dyld_stub_printf () 1: x/i $pc 0x100000f56: pushq $0xc (gdb) 0x0000000100000f5b in dyld_stub_printf () 1: x/i $pc 0x100000f5b: jmpq 0x100000f3c (gdb) 0x0000000100000f3c in dyld_stub_printf () 1: x/i $pc 0x100000f3c: lea 0xe...

...eakpoint 1, 0x0000000100001c19 in main () > (gdb) display/i $pc > 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 <dyld_stub___cxa_throw> > (gdb) si > 0x0000000100016386 in dyld_stub___cxa_throw () > 2: x/i $pc 0x100016386 <dyld_stub___cxa_throw>: jmpq *0xae1c(%rip) # 0x1000211a8 > (gdb) > 0x0000000102244870 in __cxa_throw () > 2: x/i $pc 0x102244870 <__cxa_throw>: jmpq 0xffd27000 > (gdb) # the above its __cxa_throw in gcc's libstdc++.6.dylib. The first instruction has been patch to jump to a garbage address....

Hi, What kind of C/C++ high level code can generate a computed jump, such as: jmpq *%r14 or jmpq *(%r14,%rbx,8) ? I imagine that any calls (including virtual) would use something like 'call *%r14', and the above jumps are mostly from 'switch' statements. Is this correct? Anything else? Thank you, Dan _________________________________________...

...function. Then I save the object code into a file after implementing notifyObjectCompiled method. IrExprGetValue: 0x00007fe4cc6c2000: push %rbp 0x00007fe4cc6c2001: mov %rsp,%rbp 0x00007fe4cc6c2004: mov 0x10(%rdi),%rax 0x00007fe4cc6c2008: pop %rbp 0x00007fe4cc6c2009: jmpq *%rax 0x00007fe4cc6c200b: nopl 0x0(%rax,%rax,1) JittedOpExpr: 0x00007fe4cc6c2010: push %rbp 0x00007fe4cc6c2011: mov %rsp,%rbp *0x00007fe4cc6c2014: movabs $0x7fe4801fa1f8,%rax* 0x00007fe4cc6c201e: movabs $0x7fe4801fa1e8,%rdi 0x00007fe4cc6c2028: callq *(%rax) 0x00007fe...

On Tue, Oct 23, 2012 at 02:03:15PM -0700, Nick Kledzik wrote: > > On Oct 23, 2012, at 1:57 PM, Jack Howarth wrote: > > Nick, > > Can I do this without access to a debug version of dyld? Using the copy of LLVMPolly.so with isl/cloog-isl/gmp statically linked, > > I find that if I set the breakpoint to the address of the initializer... > > > > dyld: calling

...in main () > > (gdb) display/i $pc > > 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 > <dyld_stub___cxa_throw> > > (gdb) si > > 0x0000000100016386 in dyld_stub___cxa_throw () > > 2: x/i $pc 0x100016386 <dyld_stub___cxa_throw>: jmpq > *0xae1c(%rip) # 0x1000211a8 > > (gdb) > > 0x0000000102244870 in __cxa_throw () > > 2: x/i $pc 0x102244870 <__cxa_throw>: jmpq 0xffd27000 > > (gdb) # the above its __cxa_throw in gcc's libstdc++.6.dylib. The > first instruction has been patch to...

...b) display/i $pc > > > 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 > > <dyld_stub___cxa_throw> > > > (gdb) si > > > 0x0000000100016386 in dyld_stub___cxa_throw () > > > 2: x/i $pc 0x100016386 <dyld_stub___cxa_throw>: jmpq > > *0xae1c(%rip) # 0x1000211a8 > > > (gdb) > > > 0x0000000102244870 in __cxa_throw () > > > 2: x/i $pc 0x102244870 <__cxa_throw>: jmpq 0xffd27000 > > > (gdb) # the above its __cxa_throw in gcc's libstdc++.6.dylib. The > > first...

Jack, can you please upload this test somewhere? On Thu, Nov 29, 2012 at 10:09 AM, Kostya Serebryany <kcc at google.com> wrote: > +glider > The compiler hardly matters here, I would expect the same failures with > clang. > Alex, could you please take a look? > > --kcc > > > On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >

...; } else { d = a * 51; } bar(b, d); } clang.7.0.1 -O2, LLVM generated assembly: 0: 6b c7 3a imul $0x3a,%edi,%eax 3: 6b f7 33 imul $0x33,%edi,%esi 6: 89 c7 mov %eax,%edi 8: e9 00 00 00 00 jmpq d <foo+0xd> GCC.5.2.0 -O3, GCC generated assembly: 0: 83 ff 72 cmp $0x72,%edi 3: 7f 0b jg 10 <foo+0x10> 5: 6b f7 33 imul $0x33,%edi,%esi 8: 89 c7 mov %eax,%e...

...tmp0 nopw 512(%rax,%rax,1) .Ltmp0: // rest of the code Is there a way of forcing the lowered JMP instruction to turn into a two-byte jump that does a short relative jump (one that fits within 8 bits)? When I run the binary and disassemble the function I'm seeing it turn into a 5-byte jump (jmpq <32-bit offset>) instead of a 2-byte jump (jmp <8-bit offset>). Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160622/e14aea1d/attachment.html>

...b) display/i $pc > > > 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 > > <dyld_stub___cxa_throw> > > > (gdb) si > > > 0x0000000100016386 in dyld_stub___cxa_throw () > > > 2: x/i $pc 0x100016386 <dyld_stub___cxa_throw>: jmpq > > *0xae1c(%rip) # 0x1000211a8 > > > (gdb) > > > 0x0000000102244870 in __cxa_throw () > > > 2: x/i $pc 0x102244870 <__cxa_throw>: jmpq 0xffd27000 > > > (gdb) # the above its __cxa_throw in gcc's libstdc++.6.dylib. The > > first...

...de11c41f3: cmpl $0x63,(%rax) > 0x00007f0de11c41f6: jg 0x7f0de11c420c > 0x00007f0de11c41fc: mov 0x8(%r10),%rax > 0x00007f0de11c4200: incl (%rax) > 0x00007f0de11c4202: mov (%r10),%rax > 0x00007f0de11c4205: incl (%rax) > 0x00007f0de11c4207: jmpq 0x7f0de11c41f0 > 0x00007f0de11c420c: xor %rax,%rax > 0x00007f0de11c420f: retq > > I use init_trampoline to generate code that sets up the static link: > > 0x00007fffee982316: mov $0x7f48e1a08fb0,%r11 > 0x00007fffee982320: mov $0x7fffee982330,%r10...

...; > > 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 > > > <dyld_stub___cxa_throw> > > > > (gdb) si > > > > 0x0000000100016386 in dyld_stub___cxa_throw () > > > > 2: x/i $pc 0x100016386 <dyld_stub___cxa_throw>: jmpq > > > *0xae1c(%rip) # 0x1000211a8 > > > > (gdb) > > > > 0x0000000102244870 in __cxa_throw () > > > > 2: x/i $pc 0x102244870 <__cxa_throw>: jmpq 0xffd27000 > > > > (gdb) # the above its __cxa_throw in gcc's libstdc++.6.dy...

...5: 23 07 and (%rdi),%eax > 7: 3d 00 00 00 01 cmp $0x1000000,%eax > c: 75 05 jne 13 > <_Z6xfuncxPKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoEPNS_9BitVectorE+0x13> > > e: e9 00 00 00 00 jmpq 13 > <_Z6xfuncxPKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoEPNS_9BitVectorE+0x13> > > 13: 48 89 d6 mov %rdx,%rsi > 16: e9 00 00 00 00 jmpq 1b <.LCPI5_1+0xb> > > It grabs the low word of the MO and uses a mask to grab bit...

...of section .idata$6: 0000 55534552 33322e64 6c6c0000 USER32.dll.. I recreated the hello64.test using dlltool for the lib and here is the asm dump of the final exe hello64gnu.exe: file format COFF-x86-64 Disassembly of section .text: .text: 3000: ff 25 26 f0 ff ff jmpq *-4058(%rip) 3006: 90 nop 3007: 90 nop 3008: ff 25 26 f0 ff ff jmpq *-4058(%rip) 300e: 90 nop 300f: 90 nop 3010: 48 83 ec 28 subq $40, %rsp 3014: 48 c7 c1 00 00 00 00 movq $0, %rcx...

(llvm 2.6) We have an application where we are using LLVM to generate ELF object files for X86_64. At runtime we load these objects files into memory using our own ELF loader. Everything is working except for the jump tables. The ELF emitter is generating JMPQ instructions using X86::reloc_absolute_word_sext relocations which we are unable to patch to the jump table in the .rodata segment unless we force that segment to load in the low 2GB of the address range. Currently we just request pages of memory from the OS and that memory is much deeper in the a...

...;> > > 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 >> > <dyld_stub___cxa_throw> >> > > (gdb) si >> > > 0x0000000100016386 in dyld_stub___cxa_throw () >> > > 2: x/i $pc 0x100016386 <dyld_stub___cxa_throw>: jmpq >> > *0xae1c(%rip) # 0x1000211a8 >> > > (gdb) >> > > 0x0000000102244870 in __cxa_throw () >> > > 2: x/i $pc 0x102244870 <__cxa_throw>: jmpq 0xffd27000 >> > > (gdb) # the above its __cxa_throw in gcc's libstdc++.6.dylib....

...pc 0x100001c19 <main+318>: callq 0x100016386 > > > > <dyld_stub___cxa_throw> > > > > > (gdb) si > > > > > 0x0000000100016386 in dyld_stub___cxa_throw () > > > > > 2: x/i $pc 0x100016386 <dyld_stub___cxa_throw>: jmpq > > > > *0xae1c(%rip) # 0x1000211a8 > > > > > (gdb) > > > > > 0x0000000102244870 in __cxa_throw () > > > > > 2: x/i $pc 0x102244870 <__cxa_throw>: jmpq 0xffd27000 > > > > > (gdb) # the above its __cxa_throw in...