|
From: Joerg W. <wa...@it...> - 2009-02-17 10:10:03
|
Hello, reading from the manual I see that atomic instructions (like lock inc, etc. on x86) are not supported by valgrind in the sense of being emulated in a correct way. What is the technical reason for this? Are there any plans to correctly handle these instructions? What is the technical difference between handling these and handling pthread's mutexes? Can't valgrind put something like fake mutexes 'around' these atomic variables whenever such an operation is used? Thanks for some insights here, regards! Joerg |
|
From: Nicholas N. <n.n...@gm...> - 2009-02-17 23:18:00
|
On Tue, Feb 17, 2009 at 7:57 PM, Joerg Wagner <wa...@it...> wrote: > > reading from the manual I see that atomic instructions > (like lock inc, etc. on x86) are not supported by valgrind > in the sense of being emulated in a correct way. > > What is the technical reason for this? Are there any > plans to correctly handle these instructions? What > is the technical difference between handling these and > handling pthread's mutexes? Can't valgrind put something > like fake mutexes 'around' these atomic variables whenever > such an operation is used? Here's my understanding, which may not be completely right. Each original machine instruction can be translated into multiple instructions. First, because Valgrind's internal format is RISC-like, so complex instructions like the x86 'push' instruction get broken into multiple instructions. Second, because tools add more instructions. To give you an idea, code produced by Memcheck is typically 15x larger than the original code. However, Valgrind serialises multi-threaded execution anyway, so I'm not sure if losing the atomicity is a problem. Also, using software-based locks to emulate hardware-based locks would be slow, but perhaps these instructions are rare enough that it wouldn't be that bad. Nick |
|
From: Bart V. A. <bar...@gm...> - 2009-02-18 18:31:24
|
On Tue, Feb 17, 2009 at 11:16 PM, Nicholas Nethercote <n.n...@gm...> wrote: > However, Valgrind serialises multi-threaded execution anyway, so I'm > not sure if losing the atomicity is a problem. IMHO losing atomicity is definitely a problem in the following case (there might be more examples): a process running under Valgrind on a system with multiple cores or CPU's is updating a location in memory through atomic instructions, where that memory is shared with another process. This issue has been discussed before on the valgrind-devel mailing list. In that discussion Julian stated that he has already been considering to implement proper support for atomic instructions in the VEX library. See also: http://thread.gmane.org/gmane.comp.debugging.valgrind.devel/5471. Bart. |