Documentation/Debugging: Difference between revisions

From QEMU
(Created page with '== Using valgrind == You can use [http://www.valgrind.org valgrind] to detect memory corruption and leaks within QEMU. valgrind really doesn't function well when using KVM so i…')
 
No edit summary
Line 2: Line 2:


You can use [http://www.valgrind.org valgrind] to detect memory corruption and leaks within QEMU.  valgrind really doesn't function well when using KVM so it's advised to use TCG.  Additionally, you will need to use the <code>--smc-check=all</code> option to instruct valgrind to detect self-modifying which TCG makes extensive use of.
You can use [http://www.valgrind.org valgrind] to detect memory corruption and leaks within QEMU.  valgrind really doesn't function well when using KVM so it's advised to use TCG.  Additionally, you will need to use the <code>--smc-check=all</code> option to instruct valgrind to detect self-modifying which TCG makes extensive use of.
== Using gdb ==
You can use gdb in a range of ways.
If you invoke qemu from within gdb, you'll probably want to skip SIGUSR2 ("handle SIGUSR2 noprint").
You can also invoke qemu with the -gdb option (or -s shortcut) which provides a gdb stub. You can then connect from any machine on the network. See the man page for more information.
Depending on what you are trying to debug, it may help to use the -S option to qemu (which freezes the cpu on startup), so you can get qemu up, attach gdb and get it set up, then continue.

Revision as of 00:02, 10 April 2011

Using valgrind

You can use valgrind to detect memory corruption and leaks within QEMU. valgrind really doesn't function well when using KVM so it's advised to use TCG. Additionally, you will need to use the --smc-check=all option to instruct valgrind to detect self-modifying which TCG makes extensive use of.

Using gdb

You can use gdb in a range of ways.

If you invoke qemu from within gdb, you'll probably want to skip SIGUSR2 ("handle SIGUSR2 noprint").

You can also invoke qemu with the -gdb option (or -s shortcut) which provides a gdb stub. You can then connect from any machine on the network. See the man page for more information.

Depending on what you are trying to debug, it may help to use the -S option to qemu (which freezes the cpu on startup), so you can get qemu up, attach gdb and get it set up, then continue.