[Valgrind-users] Helgrind to-do list

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

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