Detect every memory accesses made by a C/C++ program -

i trying detect every access programs written in c/c++ making while running, in particular dynamically allocated memory. in addition, have information access made. function name made access looking for.

for example, following code:

void memoryaccess(int* my_vector) {     int x = my_vector[0]; // read access 0xffff0000.     my_vector[0] = x + 1; // write access 0xffff0000. }  int main(void) {     // assume address returned malloc 0xffff0000.     int* vec = malloc(vec_size * sizeof(int));     if (!vec) {         return memory_allocation_fail;     }     memoryaccess(vec);      int second_elem = vec[1]; // read access 0xffff0004.     v[1] = 10; // write access 0xffff0004.      return 0; } 

i record log file, containing following: address have been accessed, function name made access. above example, log should like:

{read}  {memoryaccess} {0xffff0000} {write} {memoryaccess} {0xffff0000} {read}  {main}         {0xffff0004} {write} {main}         {0xffff0004} 

i have been able on windows using exception filter , modify page protection of monitored memory block. couldn't function name made access, instruction pointer value when exception raised , couldn't figure how use function name.

note: goal monitor memory access on linux based system (debian/ubuntu mostly), not windows.

^{(i focusing on linux)}

what want very slow , need unportable code if done naively. supposing want generic solution (working on many c++ programs, not on particular one).

you patch emulator, à la qemu.

maybe want use valgrind or gcc debugging options address sanitizer (search -fsanitize=address). or use gdb watchpoints. notice recent gdb scriptable in python or guile.

maybe take inspiration valgrindtricks.

look ptrace(2)

if don't want disastrous performance (that is, naively interpreting each machine instruction and/or handling sigsegv every memory access, see this more) need tricky.

you consider customizing gcc compiler (e.g. melt) (relevant) loads & stores instrumented inside compiler.

if take naive approach (sort of interpreting every machine instruction and/or crude sigsegv handling), you'll slow program more factor of thousand, , "semi-naive" approach still needs months of work. , you'll encounter heisenbugs.

if want serious approach, you'll need modify gcc compiler (e.g. melt) instrumentation code additionally emitted compiler, recompile program instrumented (and libraries using) , take @ least year (unless fluent gcc internals).

if serious, study more computer science (computer architecture, operating systems, compilers), , make phd working on that. you'll need several years of hard work.