On Thu, 2012-11-29 at 06:25 -0800, John Reiser wrote: > This is good as far as it goes. The presentation in the output from > "valgrind --help" will matter, and so will the explanation given > in the user manual. Just finding and understanding the new options > is a significant barrier to usability. Try to write things so that > applying "grep" gives good hints about where to read further. > (This may include rewriting _other_ pieces in order to reduce > "false positive" usage of key words.) The patch contains the --help and the updates to the manual. Feedback welcome ...
> > More generally, why isn't this controllable by a loadable Python module, > complete with defaults (including a complete default error handling module) > and introspection? There should be ways to find > all existing suppressions, how many times each one has been applied > so far, the current traceback, the "type" of the current error, etc. > If coregrind doesn't want to deal with Python, then have gdb do it. Integrate a Python interpreter inside Valgrind seems quite a lot of work. It is not clear to me if the possible usage(s) would justify it. Using the python interpreter in GDB (via the Valgrind gdbsrv) is ok as long as it accesses the "guest process" data. I do not know a way to persuade GDB that the process also has "Valgrind tool" data (and code). Philippe ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
