|
From: pankaj p. <pan...@gm...> - 2011-07-07 13:28:08
|
Hi all, I had doubt regarding the flattened IR for a call instruction. When I try and print the IR statements for call instructions, i can see the return instruction being written on the stack but i am unable to see how the branching is being done. I can't capture it in Ist_Exit . Can someone explain me what am I missing. Thanks, pankaj |
|
From: Josef W. <Jos...@gm...> - 2011-07-07 15:07:42
|
On Thursday 07 July 2011, pankaj pawan wrote: > Hi all, > > I had doubt regarding the flattened IR for a call instruction. When I try > and print the IR statements for call instructions, i can see the return > instruction being written on the stack but i am unable to see how the > branching is being done. > I can't capture it in Ist_Exit . A call is nothing more than an unconditional jump with putting a return address on the stack. As such, the call will disappear in the middle of a superblock. You could detect that there is a jump in the addresses of subsequent guest instructions, but AFAIK, there is no way to detect whether it just was a jump or a call (*). Instead, you can prohibit the building of superblocks by setting VEX attributes VG_(clo_vex_control).iropt_unroll_thresh = 0; VG_(clo_vex_control).guest_chase_thresh = 0; in your tool initialization (as callgrind does). Then, a call should end a BB, and IRSB attribute jumpkind should be Ijk_Call if the BB ends in a guest call instruction. Josef (*) It can make sense to add a VEX noop IR hint about that there was a given call/jump in the middle of a superblock translation. But only if a tool really would need it... > > Can someone explain me what am I missing. > > Thanks, > pankaj > |
|
From: pankaj p. <pan...@gm...> - 2011-07-07 15:35:48
|
Hi Josef, Thanks for your reply. I did run valgrind with guest_chase_thresh = 0 and was able to do capture the calls. But my doubt was that I can't see the jump statement(is it that unconditional jumps are not displayed in IR) Sorry I am new, but an unconditional branch we should just set the IP to the called location?Am I right? How it this being taken care of in the IR? I also had another question : Can we read the values written on stack. For example if I want to get the arguments being passed to a certain function? I have been able to intercept the calls to that particular function and get the Stack Pointer. How do I read the stack values? Regards, pankaj On Thu, Jul 7, 2011 at 5:07 PM, Josef Weidendorfer < Jos...@gm...> wrote: > On Thursday 07 July 2011, pankaj pawan wrote: > > Hi all, > > > > I had doubt regarding the flattened IR for a call instruction. When I try > > and print the IR statements for call instructions, i can see the return > > instruction being written on the stack but i am unable to see how the > > branching is being done. > > I can't capture it in Ist_Exit . > > A call is nothing more than an unconditional jump with putting a return > address > on the stack. As such, the call will disappear in the middle of a > superblock. > You could detect that there is a jump in the addresses of subsequent guest > instructions, but AFAIK, there is no way to detect whether > it just was a jump or a call (*). > > Instead, you can prohibit the building of superblocks by setting VEX > attributes > > VG_(clo_vex_control).iropt_unroll_thresh = 0; > VG_(clo_vex_control).guest_chase_thresh = 0; > > in your tool initialization (as callgrind does). > Then, a call should end a BB, and IRSB attribute jumpkind should be > Ijk_Call > if the BB ends in a guest call instruction. > > Josef > > (*) It can make sense to add a VEX noop IR hint about that there was a > given > call/jump in the middle of a superblock translation. But only if a tool > really > would need it... > > > > > > Can someone explain me what am I missing. > > > > Thanks, > > pankaj > > > > > |
|
From: Josef W. <Jos...@gm...> - 2011-07-08 13:06:05
|
On Thursday 07 July 2011, pankaj pawan wrote: > Hi Josef, > > Thanks for your reply. I did run valgrind with > guest_chase_thresh = 0 and was able to do capture the calls. > > But my doubt was that I can't see the jump statement(is it that > unconditional jumps are not displayed in IR) > Sorry I am new, but an unconditional branch we should just set the IP to the > called location?Am I right? > How it this being taken care of in the IR? See the IRSB structure definition in "libvex_ir.h". The final jump is specified there by jumpkind/next. > I also had another question : > > Can we read the values written on stack. For example if I want to get the > arguments being passed to a certain function? > > I have been able to intercept the calls to that particular function and get > the Stack Pointer. How do I read the stack values? If you know that a given function uses the calling conventions of a given ABI, and you know the number of arguments and types, you can directly access the stack to get at parameter values. Otherwise, you need to parse debug information. I suppose you need to extend the debug info reader to be able to forward such information to tools. Josef |
|
From: pankaj p. <pan...@gm...> - 2011-07-08 13:19:23
|
Hi Josef, Thanks for the reply. > If you know that a given function uses the calling conventions of a given > ABI, > and you know the number of arguments and types, you can directly access the > stack to get at parameter values. Otherwise, you need to parse debug > information. > I suppose you need to extend the debug info reader to be able to forward > such > information to tools. > I know the arguments and their types. I can get the stackpointer during runtime but how do I read the stack after that. Can I read memory just by dereferencing the stack pointer? Could you point to some functions which will help me in doing so. Regards, pankaj |
|
From: Josef W. <Jos...@gm...> - 2011-07-08 13:51:40
|
On Friday 08 July 2011, pankaj pawan wrote: > I know the arguments and their types. > I can get the stackpointer during > runtime but how do I read the stack after that. > Can I read memory just by dereferencing the stack pointer? VEX of course can read from memory, see IRExpr_Load. Or if you instrument a call back function, this function can just access memory on the client stack (e.g. if you pass the stack pointer as parameter). Be note that this is platform dependend. Another option is use wrapper functions, see 3.2 at http://valgrind.org/docs/manual/manual-core-adv.html Josef > Could you point to some functions which will help me in doing so. > > Regards, > pankaj > |