2

I would like to generate a log of all virtual memory accesses performed in user mode and kernel mode as a result of running some program.

Besides collecting memory access locations, I also want to capture other state information (e.g., instruction pointer, thread identifier). I anticipate that I won't be able to collect all of my desired statistics with any tool out of the box.

I intend on doing this profiling off-line, so I'm not concerned about the performance impacts. In fact, depending on what is available, it would be helpful to know which tools can record all memory accesses and which can only sample.

I was originally going to augment Valgrind's lacky tool until I realized that it only records user mode memory accesses. Looking into what other tools I might use, I'm at a loss at how I can quickly determine which tool is capable of capturing the information I want.

Here are some resources I've found that have gotten me started:

1 Answer 1

0

I wanted to update my question with the information I found in case someone else ever has a similar question.

My understanding of Linux tracing tools is that most use probes (which I'm using to describe instrumentation that is dynamically inserted into an executable's binary) and tracepoints (which I'm using to describe instrumentation compiled into code that can be enabled or disabled) to track larger scale events (e.g., function calls). As a result, these tools are not helpful for tracing something as fine grain as memory accesses.

Valgrind is very useful for tracing all memory accesses made by user code (but not kernel code because it executes the program on a synthetic CPU). From the docs:

Your program is then run on a synthetic CPU provided by the Valgrind core. As new code is executed for the first time, the core hands the code to the selected tool. The tool adds its own instrumentation code to this and hands the result back to the core, which coordinates the continued execution of this instrumented code.

This would seem to suggest that such trace information needs to be collected at the level of the component that hands off each instruction to be executed. Therefore, without using a simulator, there doesn't seem to be a method for getting this depth and breadth of information when executing user and kernel code.

This brings me to the only solution I've found: perf_event_open(). It can sample memory accesses using the performance monitoring unit (PMU) of the processor. perf_event_open() can provide a sufficient depth of information (e.g., instruction pointer, memory address, program registers) but not breadth (since it can only sample memory accesses).

(Additionally, the perf mem frontend is a good and easy place to start collecting such information about memory accesses. Samples can then be processed offline using perf script.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.