After hacking away 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. >> After each virtual call I'm calling 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 little >> strange is that the pointers are somewhat close: >> getPointerToFunction returns 0x47829a0, but my instrumentation gets >> 0x477fc10. > > This should basically work. You'll have to walk through the various > code that populates the maps. It could be that the start of the > function is actually a constant pool or jump table or something, not > the first instruction of the function. > > -Chris > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Feb 12, 2008, at 5:08 PM, Robert Zeh wrote:> After hacking away at it for a bit, it looks like the mystery > function is actually a stub function.You know, I had this lengthy email written to cover all the details and I decided not to send it as I wasn't sure if that was what you were hitting a stub and I didn't want to confuse the issue 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 > functionsI 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
On Feb 12, 2008, at 5:08 PM, Robert Zeh wrote:> After hacking away 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?Do you care about JIT laziness? You could just call getPointerToFunction on every function in the module before your code starts up. -Chris
I thought about it --- that's actually how I figured out that I was getting the stub functions --- but the laziness is nice for my application. The bitcode module I'm working with is about 3.8 megabytes. I've been assuming it would take a while to compile each function, a chunk of which I probably won't need (but won't be able to tell until I get my input.) Robert On Feb 12, 2008, at 10:45 PM, Chris Lattner wrote:> > On Feb 12, 2008, at 5:08 PM, Robert Zeh wrote: > >> After hacking away 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? > > Do you care about JIT laziness? You could just call > getPointerToFunction on every function in the module before your code > starts up. > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Here is a patch that will do just that. The patch brings up three questions: Is it ok for ExecutionEngine::getGlobalValueAtAddress to be virtual? Did I handle the locking properly in my changes to JITEmitter. Are there other places that have to be changed for this to work right? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: getGlobalValueForStubs.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080223/8f407410/attachment.txt> -------------- next part -------------- Robert On Feb 12, 2008, at 9:11 PM, Mike Stump wrote:> On Feb 12, 2008, at 5:08 PM, Robert Zeh wrote: >> After hacking away at it for a bit, it looks like the mystery >> function is actually a stub function. > > You know, I had this lengthy email written to cover all the details > and I decided not to send it as I wasn't sure if that was what you > were hitting a stub and I didn't want to confuse the issue 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Here is a patch that will do just that. The patch brings up three questions: Is it ok for ExecutionEngine::getGlobalValueAtAddress to be virtual? Did I handle the locking properly in my changes to JITEmitter. Are there other places that have to be changed for this to work right? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: getGlobalValueForStubs.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080227/2a32909d/attachment.txt> -------------- next part -------------- On Feb 12, 2008, at 9:11 PM, Mike Stump wrote:> On Feb 12, 2008, at 5:08 PM, Robert Zeh wrote: >> After hacking away at it for a bit, it looks like the mystery >> function is actually a stub function. > > You know, I had this lengthy email written to cover all the details > and I decided not to send it as I wasn't sure if that was what you > were hitting a stub and I didn't want to confuse the issue 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev