[Valgrind-users] FW: Helgrind to-do list

[Phil L. <plo...@sa...>]

Travis has commented about the need for #2 for a few suppressions.  I have at least 1 case of #1 in the PDB tree.

From: Phil Longstaff
Sent: Wednesday, September 25, 2013 2:24 PM
To: val...@li...
Subject: Helgrind to-do list

The bottom of the helgrind section of the manual has:

*         For lock order errors, print the complete lock cycle, rather than only doing for size-2 cycles as at present.

*         The conflicting access mechanism sometimes mysteriously fails to show the conflicting access' stack, even when provided with unbounded storage for conflicting access info. This should be investigated.

*         Document races caused by GCC's thread-unsafe code generation for speculative stores. In the interim see http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html and http://lkml.org/lkml/2007/10/24/673.

*         Don't update the lock-order graph, and don't check for errors, when a "try"-style lock operation happens (e.g. pthread_mutex_trylock). Such calls do not add any real restrictions to the locking order, since they can always fail to acquire the lock, resulting in the caller going off and doing Plan B (presumably it will have a Plan B). Doing such checks could generate false lock-order errors and confuse users.

*         Performance can be very poor. Slowdowns on the order of 100:1 are not unusual. There is limited scope for performance improvements.
I'm interested in solutions for a couple of those (#1, #2 and #4).  Is any work being done on them?  If I were to try to tackle them, can someone at least point me in the right place in the code?

Phil