Hello, everyone I am a newbie of DTrace and OpenSolaris. Just wondering is it possible to trace every memory read/write of a specific process given the pid? Basically speaking, I want to record the virtual addresses being accessed by the process, using which I will try to do some online analysis. If DTrace does not support this type of instrumentation, will other tools in OpenSolaris help me achieve that, such as mdb, and etc? Thanks! Peng Du Feb 12, 2009
Hi Peng, You can''t do this today with DTrace though a watchpoint provider has been a long-standing RFE (that''s I''d love to get to soon!). For now your best bet is mdb. Adam On Feb 13, 2009, at 9:34 AM, Peng Du wrote:> Hello, everyone > > I am a newbie of DTrace and OpenSolaris. Just wondering is it possible > to trace every memory read/write of a specific process given the pid? > Basically speaking, I want to record the virtual addresses being > accessed by the process, using which I will try to do some online > analysis. > > If DTrace does not support this type of instrumentation, will other > tools in OpenSolaris help me achieve that, such as mdb, and etc? > > Thanks! > > Peng Du > Feb 12, 2009 > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
Hi, Adam Thanks for the hint. Do you mean this functionality is/will be deprecated? Actually, I did some experiments with hardware watchpoint yesterday, not using Dtrace, but the /proc filesystem in OpenSolaris. It seemed to work though. As I am not doing a commercial application, just a data analysis for my academic research project. The RFE issue might not be very important. However, I do have a doubt about watchpoint. So, everytime memory is accessed, a hardware trap signal is sent to the application, right? What if there are multiple threads accessing memory concurrently? In my understanding, signal handling is a block operation, so the threads should be blocked and then resumed execution after the trap is handled, correct? Will this in effect serialize the threads? If yes, there is not so much difference than merely using Valgrind, etc. Thanks Peng Du 02/16/2009 On Sun, 2009-02-15 at 19:38 -0800, Adam Leventhal wrote:> Hi Peng, > > You can''t do this today with DTrace though a watchpoint provider has > been a long-standing RFE (that''s I''d love to get to soon!). For now > your best bet is mdb. > > Adam > > On Feb 13, 2009, at 9:34 AM, Peng Du wrote: > > > Hello, everyone > > > > I am a newbie of DTrace and OpenSolaris. Just wondering is it possible > > to trace every memory read/write of a specific process given the pid? > > Basically speaking, I want to record the virtual addresses being > > accessed by the process, using which I will try to do some online > > analysis. > > > > If DTrace does not support this type of instrumentation, will other > > tools in OpenSolaris help me achieve that, such as mdb, and etc? > > > > Thanks! > > > > Peng Du > > Feb 12, 2009 > > > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org > > > -- > Adam Leventhal, Fishworks http://blogs.sun.com/ahl
> > You can''t do this today with DTrace though a watchpoint provider has > > been a long-standing RFE (that''s I''d love to get to soon!). For now > > your best bet is mdb.> Thanks for the hint. Do you mean this functionality is/will be > deprecated?I''m not sure what you mean by deprecated, but my hope is that it will be implemented at some point.> Actually, I did some experiments with hardware watchpoint yesterday, not > using Dtrace, but the /proc filesystem in OpenSolaris. It seemed to work > though.That''s great. Just to clarify, the watchpoints supported by /proc don''t use the hardware watchpoint facilities provided by some CPUs.> However, I do have a doubt about watchpoint. So, everytime memory is > accessed, a hardware trap signal is sent to the application, right? What > if there are multiple threads accessing memory concurrently? In my > understanding, signal handling is a block operation, so the threads > should be blocked and then resumed execution after the trap is handled, > correct?That''s correct.> Will this in effect serialize the threads? If yes, there is not so much > difference than merely using Valgrind, etc.Also true. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
Hello, Adam Thanks for your quick reply! I got the RFE thing. Anyway, is there a way to trace memory access without affecting the actual executions of a MT app, like in an asynchronous way? For example, whenever the trap is hit, thread resumes and the signal is pooled somewhere? Or, I know there is a LWP subdirectory in the /proc/<pid> directory, containing the info of all of threads in the process. Each of which also has a CTL directory by which we can set up a watchpoint handler for that thread. I am thinking: can spawn the multiple threads, each of which handles the watchpoint trap of a thread in the process, such that we do not interfere the normal execution of the MT app? Is this possible? If we can do this asynchronously, that would be perfect, can we? Peng Du 02/16/2009 On Mon, 2009-02-16 at 09:36 -0800, Adam Leventhal wrote:> > > You can''t do this today with DTrace though a watchpoint provider has > > > been a long-standing RFE (that''s I''d love to get to soon!). For now > > > your best bet is mdb. > > > Thanks for the hint. Do you mean this functionality is/will be > > deprecated? > > I''m not sure what you mean by deprecated, but my hope is that it will be > implemented at some point. > > > Actually, I did some experiments with hardware watchpoint yesterday, not > > using Dtrace, but the /proc filesystem in OpenSolaris. It seemed to work > > though. > > That''s great. Just to clarify, the watchpoints supported by /proc don''t use > the hardware watchpoint facilities provided by some CPUs. > > > However, I do have a doubt about watchpoint. So, everytime memory is > > accessed, a hardware trap signal is sent to the application, right? What > > if there are multiple threads accessing memory concurrently? In my > > understanding, signal handling is a block operation, so the threads > > should be blocked and then resumed execution after the trap is handled, > > correct? > > That''s correct. > > > Will this in effect serialize the threads? If yes, there is not so much > > difference than merely using Valgrind, etc. > > Also true. > > Adam >
Hi Peng, There isn''t any way to memory accesses that won''t cause a multithreaded process to effectively serialize. The watchpoint facility''s lowest level mechanism would need to emulate the instructions that that''s not done today. Adam On Feb 16, 2009, at 10:04 AM, Peng Du wrote:> Hello, Adam > > Thanks for your quick reply! I got the RFE thing. Anyway, is there a > way > to trace memory access without affecting the actual executions of a MT > app, like in an asynchronous way? For example, whenever the trap is > hit, > thread resumes and the signal is pooled somewhere? > > Or, I know there is a LWP subdirectory in the /proc/<pid> directory, > containing the info of all of threads in the process. Each of which > also > has a CTL directory by which we can set up a watchpoint handler for > that > thread. I am thinking: can spawn the multiple threads, each of which > handles the watchpoint trap of a thread in the process, such that we > do > not interfere the normal execution of the MT app? Is this possible? If > we can do this asynchronously, that would be perfect, can we? > > > > Peng Du > 02/16/2009 > > > > On Mon, 2009-02-16 at 09:36 -0800, Adam Leventhal wrote: >>>> You can''t do this today with DTrace though a watchpoint provider >>>> has >>>> been a long-standing RFE (that''s I''d love to get to soon!). For now >>>> your best bet is mdb. >> >>> Thanks for the hint. Do you mean this functionality is/will be >>> deprecated? >> >> I''m not sure what you mean by deprecated, but my hope is that it >> will be >> implemented at some point. >> >>> Actually, I did some experiments with hardware watchpoint >>> yesterday, not >>> using Dtrace, but the /proc filesystem in OpenSolaris. It seemed >>> to work >>> though. >> >> That''s great. Just to clarify, the watchpoints supported by /proc >> don''t use >> the hardware watchpoint facilities provided by some CPUs. >> >>> However, I do have a doubt about watchpoint. So, everytime memory is >>> accessed, a hardware trap signal is sent to the application, >>> right? What >>> if there are multiple threads accessing memory concurrently? In my >>> understanding, signal handling is a block operation, so the threads >>> should be blocked and then resumed execution after the trap is >>> handled, >>> correct? >> >> That''s correct. >> >>> Will this in effect serialize the threads? If yes, there is not so >>> much >>> difference than merely using Valgrind, etc. >> >> Also true. >> >> Adam >> >-- Adam Leventhal, Fishworks http://blogs.sun.com/ahl