|
From: Seagle, R. L. <rs...@ut...> - 2011-05-11 03:11:15
|
Hi, I've been working on a tool similar to callgrind that collects code coverage of a specified shared library and prints a summary of all functions executed in that library after execution ceases. The output is summarized in an XML file for later parsing and scrutiny. My primary targets for this tool are programs running on Mac OS X 10.6 and on an amd64 processor. In order to print the summary information, I want the tool to react to a SIGINFO. This signal will signify that I have run the program long enough to collect all necessary traces, direct the tool to dump the information to a file in XML, and stop execution. While creating this tool, I've noticed that running 64-bit programs under Valgrind on Mac OS X 10.6 and then sending certain signals causes Valgrind to crash with an unimplemented functionality error. I traced these errors back to the VG_UCONTEXT_INSTR_PTR() function not being implemented in coregrind/m_signals.c for VGP_amd64_darwin. After realizing this, I recompiled Valgrind with the --enable-only32bit option and tried sending the same signals. It appears that Valgrind can correctly handle these signals, but they are not being passed to my tool's registered function for signal tracing. Namely, the function registered with the track_pre_deliver_signal(). I found that most of these signals are being delivered to the emulated program by the function deliver_signal() in coregrind/m_signals.c. In the deliver_signal function, It seems Valgrind is always calling the default_action() function instead of push_signal_frame() which in turn causes the VG_TRACK() for pre_deliver_signal to never be called. My questions are: 1) Is signal handling for VGP_amd64_darwin not completely supported yet? 2) Should default_action() ever call VG_TRACK() for pre_deliver_signal, so that tools can react to signals? - I added a quick patch to Valgrind to do this, and it appears to exhibit the behavior I expect and not interfere with program emulation. Thanks for the help. Roger Seagle |
|
From: Josef W. <Jos...@gm...> - 2011-05-11 12:52:13
|
On Wednesday 11 May 2011, Seagle, Roger Lee wrote: > In order to print the summary information, I want the tool to react to a SIGINFO. > This signal will signify that I have run the program long enough to collect all > necessary traces, direct the tool to dump the information to a file in > ... Just a comment about your strategy using a signal for notifying a Valgrind tool (I can not comment to your questions about support of signal handling for VGP_amd64_darwin): I think that is a bad idea. For Valgrind to be transparent to client code, it should forward all signals to the client - it could be that the client needs it. Also, even if you catch the signal in your tool, it still will be forwarded to the client; you can not prohibit it. In callgrind, I use command files, and Callgrind regularily polls for existance of a command file. For sure, this is not the perfect way, too. Just recently, with the gdbserver stuff of Philippe Waroquiers, a better way was merged to valgrind, using ptrace as way for notification. It just needs a small function to catch commands, and you use the new "vgdb" tool to send commands to a running tool. Josef |