I happened across this stackoverflow post: http://stackoverflow.com/questions/15274798/valgrind-vgdb-with-gdb-in-emacs which claims that valgrind doesn't handle the non-stop parts of the remote protocol. See: https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_002dStop.html I think it would be nice if valgrind supported this. Reproducible: Always
Supporting non stop mode looks very challenging. The major difficulty for that is that Valgrind is serialising thread execution: Valgrind has a "big lock". A thread runs (execute some code) when it has the big lock and releases it after a certain time slice. Note that when doing a blocking syscall, the thread releases the lock so as to allow other threads to execute. We might imagine to have the thread executing the gdbserver code releasing the big lock. However that would also causes a lot of difficulties, as the gdbserver code is using a lot of valgrind functions which are non thread safe (if executed without the lock). Currently, vgdb has to wait that all threads have stopped executing before establishing the connection with valgrind gdbserver. To implement the non stop mode, I think we would first have valgrind able to run multiple threads (really) in parallel. A prototype of this has been done, but at this moment, is not progressing due to no efficient solution found for parallel access to the memcheck data structures (shadow bits) by multiple threads. (see bug 301830 for the "really parallel valgrind" experiment). If/when valgrind is "really" multi-threaded (which is extremely challenging), then it might be easier to implement the non stop mode. We will then for sure need to have "fine grained locks" over the various data structures potentially used by gdbserver. For example, fine grained locks for the "input/output" functions. Some functionalities (e.g. leak search) will in any case always imply a "full stop of all threads".