similar to: [LLVMdev] indirect jumps

  Hello, I am trying to clone a machine basic block when I ran into some issues, where I am not able to make some headway. Any of yours help is highly appreciated here: My question is about Machine Basic Block Duplication:   -          Is there a utility to clone a MachineBasicBlock in LLVM? I found utility to clone machineInstrs, but couldn’t find similar utility for MachineBasicBlock. So, I

I debugged this a bit and it seems the mach_override patching of __cxa_throw is bogus. The start of that function 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

(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

Just want to emphasize that on x86-64 and using Valgrind: LLVM compiled with LLVM gets 360 unexpected test fails LLVM compiled with GCC gets 22 unexpected test fails Of course I don't know how many of these are caused by this bitfield speculation issue. John On 11/21/2016 10:48 PM, regehr via llvm-dev wrote: > Alright, here's what seems to be happening... > > The testcase

On Oct 23, 2012, at 4:46 PM, Jack Howarth wrote: > 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

Fellow developers, I'm parallelizing loops to be called by pthread. The thread body that I pass to pthread_create looks like define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) parent_frame is pointer to shared variables in original function 0x00007f0de11c41f0: mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Is the native function interposition that is being adopted based on...

Looks like this happens on x86_64 because the position of __cxa_throw is too far from the allocated branch island (should be <2G). This can be solved by allocating the branch islands somewhere near the text segment (look for kIslandEnd in asan_mac.cc, this is currently 0x7fffffdf0000) or by patching the function with a longer instruction sequence that stores the jump target in a register and

On Thu, Jun 17, 2010 at 12:38 PM, Smith, Tim <tim at bioware.com> wrote: > (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

Hi, All I have a problem to reuse mcjit jitted code loaded from ObjectCache from a file. In the first run, I use MCJIT generate function JittedOpExpr object code as following and it runs OK. 0x7fe4801fa1f8 at instruction 0x00007fe4cc6c2014 points to 0x69382E which is the beginning of ExecEvalVar function. Then I save the object code into a file after implementing notifyObjectCompiled method.

Just want to remind everyone that we plan to stop using mach_override in asanin favor of OSX's native function interposition. So, we probably don't want to spend too much effort fixing mach_override. --kcc On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote: > Looks like this happens on x86_64 because the position of __cxa_throw > is too far from

Hi, > I'm parallelizing loops to be called by pthread. The thread body that I pass > to pthread_create looks like > > define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) > parent_frame is pointer to shared variables in original function > > 0x00007f0de11c41f0: mov (%r10),%rax > 0x00007f0de11c41f3: cmpl $0x63,(%rax) > 0x00007f0de11c41f6:

I have a bit of a riddle: In http://reviews.llvm.org/D19904 I'm trying to spell the following assembly: .palign 2, 0x90 jmp +0x9 nopw 512(%rax,%rax,1) // rest of the code I try the following snippet to accomplish this: OutStreamer->EmitLabel(CurSled); OutStreamer->EmitCodeAlignment(4); auto Target = OutContext.createLinkerPrivateTempSymbol(); // Use a two-byte `jmp`.

After some more digging and creating a few testcases in lld I have narrowed it down to The fact that dlltool generates Contents of section .idata$7: 0000 55534552 33322e64 6c6c0000 USER32.dll.. Where as lld expects Contents 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

I had this problem a while back and received this response from Jeffrey. FWIW this is fixed in 2.7 by defaulting to CodeModel::Large and using indirect (far) calls. -----Original Message----- From: Jeffrey Yasskin [mailto:jyasskin at google.com] Sent: Monday, December 07, 2009 11:32 AM To: Howell, Nathan Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] 2.6 JIT using wrong address for

On Sat, Dec 01, 2012 at 05:42:15PM +0400, Kostya Serebryany wrote: > +kremenek, ganna > > On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > > > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > > Just want to remind everyone that we plan to stop using mach_override in > > > asanin favor of OSX's

+kremenek, ganna On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > Just want to remind everyone that we plan to stop using mach_override in > > asanin favor of OSX's native function interposition. > > So, we probably don't want to spend too much effort fixing

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Unless I am misunderstanding the code in asan/asan_intercepted_functions.h,

Thank you Lang. I attached the ELF object file here for your reference. Here is the IR dump of JittedOpExpr LLVM function. IrExprGetValue1 LLVM function calls to external function expr->evalfunc(expr, econtext, isNull, isDone); which should be pointed by 0x7fe4801fa1f8. However, only the first time MCJIT generated object point to expr->evalfunc but second time when program load from object

Here's some C code: extern void *GetStdHandle(unsigned int nStdHandle); extern void ExitProcess(unsigned int exit_code); extern char WriteFile(void *HANDLE, const void * lpBuffer, unsigned int nNumberOfBytesToWrite, unsigned int *lpNumberOfBytesWritten, void *lpOverlapped); static const char *message_ptr = "hello\n"; static const unsigned int message_len = 6;