Documentation/Debugging with Valgrind: Difference between revisions
Borntraeger (talk | contribs) mNo edit summary |
(mention sanitizers) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[http://www.valgrind.org Valgrind] works much like QEMU's TCG mode except it has a focus on debugging and testing. You can use it to detect memory corruption and leaks within QEMU. | = Valgrind = | ||
[http://www.valgrind.org Valgrind] works much like QEMU's TCG mode except it has a focus on debugging and testing. You can use it to detect memory corruption and leaks within QEMU as well as threading errors. | |||
== memcheck == | |||
memcheck is the default tool in valgrind and detects memory leaks, misuses of library functions, use of undefined memory and more. See [http://valgrind.org/docs/manual/mc-manual.html memcheck manual] more details. | |||
== helgrind/drd == | |||
helgrind and drd detect problems in multi-threaded programs. Right now additional work and annotations are necessary to make this useful for QEMU, as the happens-before machine of valgrind does not work very well with QEMUs rfifolock and its unlocked accesses of several shared variables via memory barriers. | |||
= KVM Based QEMU = | = KVM Based QEMU = | ||
valgrind | valgrind's memcheck tool can be used fine with KVM-based QEMU. To avoid false positives some considerations have to be made regarding KVM ioctls when writing code. | ||
Newer versions of valgrind have already some annotations for several kvm ioctls and newer versions of QEMU have patches to quiesce false positives. | |||
== ioctl handling == | |||
All ioctls have to either follow the _IO[R][W] logic or need specific handlers in valgrind. | |||
Valgrind has a default handler for unknown ioctls that parses the _IO[R][W] definition. So in case of an _IOxW ioctl with a structure as parameter, it will complain about undefined parameters if any byte of that structure is not pre-initialized. This is also true for padding and compiler alignment. | |||
The most simple "fix" is a designated initializer, e.g. | |||
<code> | |||
struct kvm_blah blah = { | |||
.field1 = 1, | |||
}; | |||
</code> | |||
= TCG Based QEMU = | = TCG Based QEMU = | ||
| Line 16: | Line 36: | ||
This is potentially complicated by the fact that a qemu-linux-user instance is usually run in a guest chroot. However with multi-arch systems you can bind mount the required ''host'' paths into your chroot so valgrind (and non-static qemu binaries) can run. | This is potentially complicated by the fact that a qemu-linux-user instance is usually run in a guest chroot. However with multi-arch systems you can bind mount the required ''host'' paths into your chroot so valgrind (and non-static qemu binaries) can run. | ||
== See Also == | |||
Another approach is to compile QEMU with a sanitizer enabled compiler. A lot of the same checks valgrind runs can be done with an instrumented build a lot faster. | |||
[[Category: | [[Category:Developer documentation]] | ||
Latest revision as of 15:20, 12 October 2016
Valgrind
Valgrind works much like QEMU's TCG mode except it has a focus on debugging and testing. You can use it to detect memory corruption and leaks within QEMU as well as threading errors.
memcheck
memcheck is the default tool in valgrind and detects memory leaks, misuses of library functions, use of undefined memory and more. See memcheck manual more details.
helgrind/drd
helgrind and drd detect problems in multi-threaded programs. Right now additional work and annotations are necessary to make this useful for QEMU, as the happens-before machine of valgrind does not work very well with QEMUs rfifolock and its unlocked accesses of several shared variables via memory barriers.
KVM Based QEMU
valgrind's memcheck tool can be used fine with KVM-based QEMU. To avoid false positives some considerations have to be made regarding KVM ioctls when writing code. Newer versions of valgrind have already some annotations for several kvm ioctls and newer versions of QEMU have patches to quiesce false positives.
ioctl handling
All ioctls have to either follow the _IO[R][W] logic or need specific handlers in valgrind.
Valgrind has a default handler for unknown ioctls that parses the _IO[R][W] definition. So in case of an _IOxW ioctl with a structure as parameter, it will complain about undefined parameters if any byte of that structure is not pre-initialized. This is also true for padding and compiler alignment. The most simple "fix" is a designated initializer, e.g.
struct kvm_blah blah = {
.field1 = 1,
};
TCG Based QEMU
You will need to use the --smc-check=all (or --smc-check=all-non-file with newer valgrind versions) option to instruct valgrind to detect self-modifying code which TCG makes extensive use of.
softmmu debugging
Valgrind can be simply run by putting the it in-front on your qemu-system invocation
linux-user debugging
This is potentially complicated by the fact that a qemu-linux-user instance is usually run in a guest chroot. However with multi-arch systems you can bind mount the required host paths into your chroot so valgrind (and non-static qemu binaries) can run.
See Also
Another approach is to compile QEMU with a sanitizer enabled compiler. A lot of the same checks valgrind runs can be done with an instrumented build a lot faster.