On Fri, Aug 01, 2014 at 07:43:08AM -0700, Zetan Drableg wrote:
Ok now we are getting somewhere! Those old vars did the trick.
libguestfs-test-tool launched with qemu-wrapper as expected with the
debug port open.
Now on to the fun part!
(gdb) set architecture i8086
The target architecture is assumed to be i8086
(gdb) break *0x7c00
Breakpoint 1 at 0x7c00
(gdb) target remote :1234
Remote debugging using :1234
0x0000fff0 in ?? ()
(gdb) cont
Continuing.
The breakpoint you documented as when the boot sector has been loaded
into memory by the BIOS and control is passed to the boot sector.
Never hits the breakpoint.....
Next steps?
Do I need to load a symbol table? Where might I find it?
This is getting very much to the edge of my experience, but yes, you
probably do need to load the symbol table, and I know how.
First install the kernel-debuginfo package that exactly corresponds to
the kernel which is being run inside the guest. You can usually tell
which kernel that is by looking at the output of supermin (it's
usually the one which has the highest version number out of all of
those "picked").
Then in the kernel-debuginfo package, find the 'vmlinux' file, eg:
$ rpm -ql kernel-debuginfo | grep vmlinux
/usr/lib/debug/lib/modules/3.14.4-200.fc20.x86_64/vmlinux
Then you can get gdb to take the symbols from that file using
the gdb command:
(gdb) symbol-file /path/to/vmlinux
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top