|
From: Ivo R. <iv...@iv...> - 2017-05-08 19:18:21
|
2017-05-08 20:39 GMT+02:00 Siddharth Nilakantan <si...@gm...>: > Hi Mike and Ivo, > > I noticed a thread where you guys had a discussion going. > > https://sourceforge.net/p/valgrind/mailman/message/35687503/ > > I was playing around with writing a tool that does some online analysis of > register reads/writes. Basically, the tool needs to know every register > read/write performed by the user program. Hi Sid, What is the ultimate goal of your analysis tool? > Due to minor ambiguity in the documentation (both in the code and the PLDI paper), I discovered the hard > way that VG_(track_post_reg_write) and VG_(track_pre_reg_read) are functions > that are called only around syscalls. I'm guessing that any VG_(track_pre_*) > and VG_(track_post_*) functions occur only around syscalls. Yes, indeed. Every tool also works with the IR (intermediate representation) - this where you can catch (and instrument) register reads and writes. I. |
|
From: Siddharth N. <si...@gm...> - 2017-05-09 07:07:00
|
Hi Ivo, The goal is to get at the Thanks, Sid On 9 May 2017 at 00:48, Ivo Raisr <iv...@iv...> wrote: > 2017-05-08 20:39 GMT+02:00 Siddharth Nilakantan <si...@gm...>: > > Hi Mike and Ivo, > > > > I noticed a thread where you guys had a discussion going. > > > > https://sourceforge.net/p/valgrind/mailman/message/35687503/ > > > > I was playing around with writing a tool that does some online analysis > of > > register reads/writes. Basically, the tool needs to know every register > > read/write performed by the user program. > > Hi Sid, > > What is the ultimate goal of your analysis tool? I want to discover the critical paths in different phases of a program, the first step of which is to able to build paths. > > Due to minor ambiguity in the documentation (both in the code and the > PLDI paper), I discovered the hard > > way that VG_(track_post_reg_write) and VG_(track_pre_reg_read) are > functions > > that are called only around syscalls. I'm guessing that any > VG_(track_pre_*) > > and VG_(track_post_*) functions occur only around syscalls. > > Yes, indeed. > Every tool also works with the IR (intermediate representation) - this > where you > can catch (and instrument) register reads and writes. > > I. > Yes this is what I had originally started doing. I found it a bit more challenging than expected. Iex_Gets represent register reads. The instrument function sees a lot of IRExpr* for Load data or Put data, which we need to recursively explore to find Iex_Gets... |
|
From: Siddharth N. <si...@gm...> - 2017-05-09 17:28:33
|
Oops. I started typing my response and then decided to respond inline. Forgot to delete my partial original response. :) On 9 May 2017 at 12:36, Siddharth Nilakantan <si...@gm...> wrote: > Hi Ivo, > > The goal is to get at the > > Thanks, > Sid > > On 9 May 2017 at 00:48, Ivo Raisr <iv...@iv...> wrote: > >> 2017-05-08 20:39 GMT+02:00 Siddharth Nilakantan <si...@gm...>: >> > Hi Mike and Ivo, >> > >> > I noticed a thread where you guys had a discussion going. >> > >> > https://sourceforge.net/p/valgrind/mailman/message/35687503/ >> > >> > I was playing around with writing a tool that does some online analysis >> of >> > register reads/writes. Basically, the tool needs to know every register >> > read/write performed by the user program. >> >> Hi Sid, >> >> What is the ultimate goal of your analysis tool? > > > I want to discover the critical paths in different phases of a program, > the first step of which is to able to build paths. > > >> > Due to minor ambiguity in the documentation (both in the code and the >> PLDI paper), I discovered the hard >> > way that VG_(track_post_reg_write) and VG_(track_pre_reg_read) are >> functions >> > that are called only around syscalls. I'm guessing that any >> VG_(track_pre_*) >> > and VG_(track_post_*) functions occur only around syscalls. >> >> Yes, indeed. >> Every tool also works with the IR (intermediate representation) - this >> where you >> can catch (and instrument) register reads and writes. >> >> I. >> > Yes this is what I had originally started doing. I found it a bit more > challenging than expected. Iex_Gets represent register reads. The > instrument function sees a lot of IRExpr* for Load data or Put data, which > we need to recursively explore to find Iex_Gets... > |