|
From: Andrew C. <ajc...@gm...> - 2011-12-08 06:46:24
|
I'm working on a memory trace visualization tool, currently based on either Lackey or a simple modification of it that writes binary data rather than ascii. I'm wondering what would be the fastest and best supported way to export large volumes of online data from a valgrind tool to another process. My tests seem to show that shared memory is the best route, but due to the limited system library support in valgrind I was unable to port this interface into a tool. Any ideas? Andrew |
|
From: Philippe W. <phi...@sk...> - 2011-12-08 21:01:05
|
> I'm working on a memory trace visualization tool, currently based on > either Lackey or a simple modification of it that writes binary data > rather than ascii. I'm wondering what would be the fastest and best > supported way to export large volumes of online data from a valgrind > tool to another process. My tests seem to show that shared memory is > the best route, but due to the limited system library support in > valgrind I was unable to port this interface into a tool. Any ideas? There is support for shared memory in Valgrind : shared memory is used between the embedded Valgrind 3.7.0 gdbserver and the vgdb relay application (vgdb relays data between gdb and Valgrind gdbserver). See e.g. file coregrind/m_gdbserver/remote-utils.c usage of VG_(am_shared_mmap_file_float_valgrind). See pub_core_aspacemgr.h and pub_tool_aspacemgr.h for the available shared memory related functionalities. Philippe |
|
From: Andrew C. <ajc...@gm...> - 2011-12-09 17:34:41
|
Thank you - I was able to hack something together using VG_(am_shared_mmap_file_float_valgrind). However there are a few things that are still incomplete: - Is there a way to use a semaphore or other synchronization primitive in the shared memory? I don't think semaphore.h is available. - I'm using shm_open() in my application, but VG_(open) in the tool - meaning that the shared memory file needs to be specified directly using the /dev/shm/... path. Is there a better way to do this? Andrew On Thu, Dec 8, 2011 at 4:00 PM, Philippe Waroquiers <phi...@sk...> wrote: >> I'm working on a memory trace visualization tool, currently based on >> either Lackey or a simple modification of it that writes binary data >> rather than ascii. I'm wondering what would be the fastest and best >> supported way to export large volumes of online data from a valgrind >> tool to another process. My tests seem to show that shared memory is >> the best route, but due to the limited system library support in >> valgrind I was unable to port this interface into a tool. Any ideas? > > > There is support for shared memory in Valgrind : shared memory is > used between the embedded Valgrind 3.7.0 gdbserver and the vgdb relay > application (vgdb relays data between gdb and Valgrind gdbserver). > > See e.g. file coregrind/m_gdbserver/remote-utils.c usage of > VG_(am_shared_mmap_file_float_valgrind). > > See pub_core_aspacemgr.h and pub_tool_aspacemgr.h for the available > shared memory related functionalities. > > Philippe > > |
|
From: Philippe W. <phi...@sk...> - 2011-12-10 09:29:08
|
> - Is there a way to use a semaphore or other synchronization primitive > in the shared memory? I don't think semaphore.h is available. Effectively, I do not think that the Valgrind core provides inter-process synchronisation mechanism. => for such missing system calls that you need, a VG_(xxxxxx) must be implemented. Note that for this, you must call the "underlying" direct syscall interface : you cannot call the "libc" layer which provides the classical user level system call. For an example, you might look at the implementation of VG_(open) in m_libcfile.c. These VG_(xxxxx) are usually trivial to implement, as soon as you know which syscall nr you need. I do not know on which underlying system calls the posix semaphores (semaphore.h) are implemented. >From what I can see, you could use __NR_futex (but this is linux only, will not work on Darwin) or the SYSV semaphores systemcalls (__NR_semget, __NR_semop, ...), corresponding to the semget, semop, ... system calls. > - I'm using shm_open() in my application, but VG_(open) in the tool - > meaning that the shared memory file needs to be specified directly > using the /dev/shm/... path. Is there a better way to do this? You are not obliged to use the /dev/shm path. For gdbserver shared memory, the shared memory file is (by default, changeable via --vgdb-prefix argument) created using VG_(open) in the TMPDIR. Philippe |