Nick, Thanks for the quick answer. Dereferencing the pointer does yield the same result in both cases but that's not what I want to do. I want to instrument the program dynamically and keep track of certain memory locations which is a problem if the same variable has different addresses for the static/dynamic code - as far I see this is what it's happening but I have no clue why. Paul On Sun, May 24, 2009 at 10:15 PM, Nick Lewycky <nicholas at mxc.ca> wrote:> Paul Martin wrote: > > Hi, > > I have the following code, the lines preceded by `>` being added at > > runtime (the snipped was also printed at runtime) > > > > define i32 @myfunc(i32 %pi) { > > entry: > > %pi_addr = alloca i32 ; <i32*> [#uses=3] > > %retval = alloca i32 ; <i32*> [#uses=2] > > %tmp = alloca i32 ; <i32*> [#uses=2] > > > %ptr32 = alloca i32 ; <i32*> [#uses=2] > > %"alloca point" = bitcast i32 0 to i32 ; <i32> [#uses=0] > > > > > store i32 %pi, i32* %ptr32 > > > %ptr8 = bitcast i32* %ptr32 to i8* ; <i8*> > [#uses=1] > > > call void @roc( i8* %ptr8 ) > > > > store i32 %pi, i32* %pi_addr > > %pi_addr1 = bitcast i32* %pi_addr to i8* ; <i8*> > > [#uses=1] > > call void @roc( i8* %pi_addr1 ) > > ... > > > > void roc(void*) is a function that only prints its argument as an > integer. > > So it's printing the pointer. > > > I was expecting for the program to print the same thing twice (the > > address of the myfunc argument) because the code added at runtime looks > > to me identical with the code that was compiled (3 lines each). > > However, that was not the case; what I got was: > > > > 147156320 > > 147117168 > > > > What am I missing? > > Make roc() dereference the pointers it's given and print that instead. > > Nick > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090524/3a4f7735/attachment.html>
Paul Martin wrote:> > Nick, > Thanks for the quick answer. > Dereferencing the pointer does yield the same result in both cases but > that's not what I want to do. I want to instrument the program > dynamically and keep track of certain memory locations which is a > problem if the same variable has different addresses for the > static/dynamic code - as far I see this is what it's happening but I > have no clue why.If you look at the LLVM IR you can see two distinct alloca instructions, the one your static code had named "%pi_addr" and the one you created named "%ptr32". It sounds like what you want to do is instead of creating your own stack spot to store %pi into, you should look at the first user of %pi which should be a store of %pi into its stack space, as generated by the static compilation, and pull the stack slot out of there. Something like this: (Given Argument *A to look for:) Value *StackSlot = 0; if (StoreInst *SI = dyn_cast<StoreInst>(*A->use_begin())) StackSlot = SI->getPointerOperand(); though I haven't actually tried to compile or run that. Nick> Paul > > On Sun, May 24, 2009 at 10:15 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Paul Martin wrote: > > Hi, > > I have the following code, the lines preceded by `>` being added at > > runtime (the snipped was also printed at runtime) > > > > define i32 @myfunc(i32 %pi) { > > entry: > > %pi_addr = alloca i32 ; <i32*> [#uses=3] > > %retval = alloca i32 ; <i32*> [#uses=2] > > %tmp = alloca i32 ; <i32*> [#uses=2] > > > %ptr32 = alloca i32 ; <i32*> [#uses=2] > > %"alloca point" = bitcast i32 0 to i32 ; <i32> > [#uses=0] > > > > > store i32 %pi, i32* %ptr32 > > > %ptr8 = bitcast i32* %ptr32 to i8* ; <i8*> > [#uses=1] > > > call void @roc( i8* %ptr8 ) > > > > store i32 %pi, i32* %pi_addr > > %pi_addr1 = bitcast i32* %pi_addr to i8* ; > <i8*> > > [#uses=1] > > call void @roc( i8* %pi_addr1 ) > > ... > > > > void roc(void*) is a function that only prints its argument as an > integer. > > So it's printing the pointer. > > > I was expecting for the program to print the same thing twice (the > > address of the myfunc argument) because the code added at runtime > looks > > to me identical with the code that was compiled (3 lines each). > > However, that was not the case; what I got was: > > > > 147156320 > > 147117168 > > > > What am I missing? > > Make roc() dereference the pointers it's given and print that instead. > > Nick > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Nick, Your solution works well if there is a store instruction in the function but in the case where there is none (i.e. the argument is passed on directly to another function), creating a store does not help to get the memory address of the variable which takes me back to my initial question at http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022590.html - isn't there a way to obtain the address of an argument? Because doing a store seems to copy the variable and expose the address of the copy - http://www.llvm.org/docs/LangRef.html#i_store is not very clear on what's going on. You can imagine that if you try to do something like taint analysis you want to track each access to a memory location - therefore something like the above would be needed. Any ideas? Thanks, Paul On Sun, May 24, 2009 at 10:47 PM, Nick Lewycky <nicholas at mxc.ca> wrote:> Paul Martin wrote: > > > > Nick, > > Thanks for the quick answer. > > Dereferencing the pointer does yield the same result in both cases but > > that's not what I want to do. I want to instrument the program > > dynamically and keep track of certain memory locations which is a > > problem if the same variable has different addresses for the > > static/dynamic code - as far I see this is what it's happening but I > > have no clue why. > > If you look at the LLVM IR you can see two distinct alloca instructions, > the one your static code had named "%pi_addr" and the one you created > named "%ptr32". > > It sounds like what you want to do is instead of creating your own stack > spot to store %pi into, you should look at the first user of %pi which > should be a store of %pi into its stack space, as generated by the > static compilation, and pull the stack slot out of there. Something like > this: > > (Given Argument *A to look for:) > Value *StackSlot = 0; > if (StoreInst *SI = dyn_cast<StoreInst>(*A->use_begin())) > StackSlot = SI->getPointerOperand(); > > though I haven't actually tried to compile or run that. > > Nick > > > Paul > > > > On Sun, May 24, 2009 at 10:15 PM, Nick Lewycky <nicholas at mxc.ca > > <mailto:nicholas at mxc.ca>> wrote: > > > > Paul Martin wrote: > > > Hi, > > > I have the following code, the lines preceded by `>` being added > at > > > runtime (the snipped was also printed at runtime) > > > > > > define i32 @myfunc(i32 %pi) { > > > entry: > > > %pi_addr = alloca i32 ; <i32*> [#uses=3] > > > %retval = alloca i32 ; <i32*> [#uses=2] > > > %tmp = alloca i32 ; <i32*> [#uses=2] > > > > %ptr32 = alloca i32 ; <i32*> [#uses=2] > > > %"alloca point" = bitcast i32 0 to i32 ; <i32> > > [#uses=0] > > > > > > > store i32 %pi, i32* %ptr32 > > > > %ptr8 = bitcast i32* %ptr32 to i8* ; <i8*> > > [#uses=1] > > > > call void @roc( i8* %ptr8 ) > > > > > > store i32 %pi, i32* %pi_addr > > > %pi_addr1 = bitcast i32* %pi_addr to i8* ; > > <i8*> > > > [#uses=1] > > > call void @roc( i8* %pi_addr1 ) > > > ... > > > > > > void roc(void*) is a function that only prints its argument as an > > integer. > > > > So it's printing the pointer. > > > > > I was expecting for the program to print the same thing twice (the > > > address of the myfunc argument) because the code added at runtime > > looks > > > to me identical with the code that was compiled (3 lines each). > > > However, that was not the case; what I got was: > > > > > > 147156320 > > > 147117168 > > > > > > What am I missing? > > > > Make roc() dereference the pointers it's given and print that > instead. > > > > Nick > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> > > http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090525/cd92972d/attachment.html>