Documentation/Debugging: Difference between revisions
m (add missing word) |
No edit summary |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
== Using valgrind == | == Using valgrind == | ||
See the page [[Documentation/Debugging with Valgrind|Debugging with Valgrind]]. | |||
== Using gdb == | == Using gdb == | ||
| Line 14: | Line 14: | ||
On some architectures, using hardware breakpoints (gdb hbreak command) may work better than software breakpoints (gdb break command) | On some architectures, using hardware breakpoints (gdb hbreak command) may work better than software breakpoints (gdb break command) | ||
[[Category:Developer documentation]] | |||
Latest revision as of 10:07, 12 October 2016
Using valgrind
See the page Debugging with Valgrind.
Using gdb
You can use gdb in a range of ways.
If you invoke qemu from within gdb, you'll probably want to skip SIGUSR1 ("handle SIGUSR1 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 (start up gdb, then use "target remote <ip>:<portnum>"). 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.
On some architectures, using hardware breakpoints (gdb hbreak command) may work better than software breakpoints (gdb break command)