Hi Phil and Stephane, Yes, the reason I want to use Pin is so that I can use the API exported by Pin to manipulate the binary and use the data gathered from the PMU using perfmon.
I have also realized that some of things i was doing earlier in my code in using perfmon were wrong, I am using perfrmon by itself to collect data by combining the techniques used in the examples. I think some of the reasons for not being able to get perfmon working with Pin could be because of this. I shall definitely try this in conjunction with Pin. Thanks for your replies! rahul On 5/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
HI Stefane, I'm not sure the message was clear, but Pin can wedge instrumentation code in around arbitrary code segments, something that pfmon cannot due. Phil > Rahul, > > On Fri, May 19, 2006 at 04:09:41PM -0600, Rahul Saxena wrote: >> >> I am trying to use perfrmon and libpfm with the Pin Instrumentation >> system. >> http://rogue.colorado.edu/Pin/index.html >> Pin is a dynamic Binary Instrumentation framework which allows users >> to write custom instrumentation and analysis routines for a binary. >> >> I am using Pin to setup a perfrmon context and a signal handler to >> handle SIGIO signals on PMU buffer overflows. Pin can setup these >> things in the same address space as the binary. >> >> I am using the SIGIO mechanism because it appears to the most >> lightweight way of gathering PMU data when the process is running. The >> reason for using Pin with perfmon is also to monitor a binary without >> recompiling it. >> > > I know about Pin but it seems overkill to use it in this context. > Perfmon can monitor unmodified binaries. In fact that's one of the top > goals. I would not use Pin just because it allows you to get control > to setup monitor. You can as well monitor a process from another one, > including for sampling. The cost is not much more. The sampling buffer > is filled up in the context of the monitored process. When the buffer > is full a message (or signal) is sent to the controlling process which > has the sampling buffer remapped. > > You can also attach to a running process. You do this by leveraging the > ptrace() interface. That is what Pin probably does too. You use ptrace > to stop (attach to) the process, attach the perfmon context, and then you > resume (detach from) the process. > > I have provided example of how to do this in the libpfm example subdir. > You can grab the latest version at: > http://perfmon2.sf.net > > > Hope this helps. > > > >> The problem I am facing is that although the PMU send buffer overflow >> signals during the period that Pin is setting up the binary to >> execute. It stops working before the code from the target binary >> executes. >> >> I have experimented to check if it is a problem with the signal >> handling, but that doesnt seem to be the case because signals are >> still caught while the target binary is running. Its just that the PMU >> information stops. >> >> I have tried counting simple things such as the number of retired >> instructions from the PMU but that too stops showing up. ( But binary >> continues to execute. ) >> >> I am not sure if the problem lies with Pin or in the way Pin interacts >> with perfmon functionality and the creation of the PMU context. Pin >> works by execing the target binary ( the one being monitored ) and >> then ptracing to take control of its execution. It then injects itself >> in the binary's address space and then interacts with the binary in >> its own address space. It can at a later point allow the binary to >> execute, independent of itself. >> >> Sorry to write a long mail, which is mostly not about perfmon, but any >> clues or questions which can help me figure out what I can do get >> perfmon to work along with Pin will be greatly appreciated. >> >> Thanks, >> rahul >> >> -- >> The World's Greatest Dream Machine >> >> _______________________________________________ >> perfmon mailing list >> [email protected] >> http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ > > -- > > -Stephane > _______________________________________________ > perfmon mailing list > [email protected] > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ >
-- The World's Greatest Dream Machine _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
