search for: getglobalvalueataddress

.... (void*)0x938742 > > then, where you use > > Constant* thp = ConstantExpr::getCast(Instruction::IntToPtr, > your_pointer_value, /* i.e. 0x938742 */ > /* your pointer type */); > > /* Now use thp */ > > change it to > > /* Now just use gv */ > > GetGlobalValueAtAddress may be useful for housekeeping. How does one use GetGlobalValueAtAddress? It returns a const GlobalValue *, but it seems that all the LLVM operations take a Value *. Any attempt to do anything with a const GlobalValue * is rejected by the C++ compiler. Perhaps I'm supposed to cast away the...

...uired parameters...); AddGlobalMapping(gv, your_pointer_value); // i.e. (void*)0x938742 then, where you use Constant* thp = ConstantExpr::getCast(Instruction::IntToPtr, your_pointer_value, /* i.e. 0x938742 */ /* your pointer type */); /* Now use thp */ change it to /* Now just use gv */ GetGlobalValueAtAddress may be useful for housekeeping. If something is wrong or not as effcient as it could be, I hope someone on the mailing list will correct me. -- Oscar

...ay at it for a bit, it looks like the mystery function is actually a stub function. The function pointer is coming from a vtable, which gets filled in with pointers to stub functions. Is there any way to do the round trip for a stub function? Two possible solutions come to mind: 1) Modify getGlobalValueAtAddress to work for pointers to stub functions 2) Add a getStubAtAddress Any other suggestions? Robert On Feb 10, 2008, at 3:41 PM, Chris Lattner wrote: > > On Feb 10, 2008, at 5:33 AM, Robert Zeh wrote: > >> I'm attempting to instrument virtual function calls in my code. >>...

...lling my own registerMethod function, with an integer marking the location of the call and a pointer to the function that was called. However, and this is where I get confused, the function pointer doesn't match any of the functions in my module. I'd hoped to call ExecutionEngine::getGlobalValueAtAddress to get a Function* for the virtual function, but ExecutionEngine::getGlobalValueAtAddress returns null. If I look up the virtual function that is getting called (with ExeuctionEngine::getPointerToFunction) it doesn't match the arguments being passed to my instrumentation. What's a...

...unction, > with an integer marking the location of the call and a pointer to > the function that was called. > > However, and this is where I get confused, the function pointer > doesn't match any of the functions in my module. I'd hoped to call > ExecutionEngine::getGlobalValueAtAddress to get a Function* for the > virtual function, but ExecutionEngine::getGlobalValueAtAddress > returns null. > > If I look up the virtual function that is getting called (with > ExeuctionEngine::getPointerToFunction) it doesn't match the > arguments being passed to my i...

...e if it wasn't due to stubs... :-( Oh well... > Is there any way to do the round trip for a stub function? Not that I know of. I think you're down to template checking (check the whole thing for strict equality please). > Two possible solutions come to mind: > 1) Modify getGlobalValueAtAddress to work for pointers to stub > functions I think I like this better. I think others might want to, need to do this same thing and I suspect they don't want to learn and they'll appreciate it just working. > 2) Add a getStubAtAddress

Hello, I've been working on turning PHP scripts into LLVM IR and I've gotten to the stage where I'm able to construct LLVM code that calls the PHP opcode handlers that I've pre-compiled to LLVM IR in the correct order. However, the PHP API is designed so that the handlers are not globally accessible (qualified by "static" in the C source). Instead they're supposed to

This is x86_64. I have a problem where an absolute memory load define i32 @foo() { entry: %0 = load i32* inttoptr (i64 12704196 to i32*) ; <i32> [#uses=1] ret i32 %0 } generates incorrect code on LLVM 2.4: 0x7ffff6d54010: mov 0xc1d9c4(%rip),%eax # 0x7ffff79719da 0x7ffff6d54016: retq should be 0x7ffff6d54010: mov 0xc1d9c4, %eax 0x7ffff6d54016: retq

...e code, I get: myglobal: 0 myglobal: 42 The first is the JIT'ted printMyGlobal() and the second is the AOT'ed printMyGlobal(). But when I lookup the address of the global variable myglobal (ee->getGlobalValueAddress()), it is mapped to the correct address. Similarly, if I lookup ee->getGlobalValueAtAddress(), I get the expected result. Am I missing an important step? Is what I am trying to do even possible? Thanks for the help. Tarun -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150914/9d1b7b26/attachment....

...looks like the mystery function > is actually a stub function. The function pointer is coming from a > vtable, which gets filled in with pointers to stub functions. > > Is there any way to do the round trip for a stub function? Two > possible solutions come to mind: > 1) Modify getGlobalValueAtAddress to work for pointers to stub > functions > 2) Add a getStubAtAddress > > Any other suggestions? Do you care about JIT laziness? You could just call getPointerToFunction on every function in the module before your code starts up. -Chris