Keilhau Timo ( Student ) wrote: > > >> -----Original Message----- >> From: >> qemu-devel-bounces+timo.keilhau.student=thomson.net@nongnu.org >> >> [mailto:qemu-devel-bounces+timo.keilhau.student=thomson.net@no > ngnu.org] On Behalf Of Jan Kiszka >> Sent: Donnerstag, 8. Mai 2008 10:29 >> To: qemu-devel@nongnu.org >> Subject: [Qemu-devel] Re: Debugging vmlinux with qemu and >> gdb. Unable to step, next, print or to get any information.. >> >> Keilhau Timo ( Student ) wrote: >>> Hello List! >>> >>> I am trying to debug linux 2.6.25 kernel with qemu -s and gdb on 64 >>> bit amd system. >>> But I am experiencing strange behaviour with qemu and gdb.. >>> Gdb stops at a given breakpoint but I cant step, next, print etc.. >>> >>> Software: >>> Host OS used: opensuse 10.3 >>> Host kernelversion: 2.6.22.5-31-default >>> guest: Debian Etch 4.0r3 amd64 >> with 2.6.25 >>> The kernel used to debug: linux-2.6.25.tar.bz2 >>> Virtualization Software: qemu pc emulator version 0.9.0 >>> Host make utillity GNU Make 3.81 >>> Host debugger: GNU gdb 6.6.50.20070726-cvs >>> (Also tried gdb 6.6, gdb 6.8 compiled from source) >>> >>> Look here: >>> >>> // Starting qemu on host: >>> >>> $ qemu-system-x86_64 -s -kernel bzImage -hda >>> qemu_mini_debian_root_fs.img -append "root=/dev/hda1" -initrd >>> debian_boot/initrd.img-2.6.25-customtk-i -no-kqemu -redir >>> tcp:10022:10.0.2.15:22 >>> >>> // Boots fine. >>> // vmlinux is compiled with CFLAGS=-g3 -ggdb, I have also >> tried only >>> with -g // On host: >>> >>> $ nm vmlinux | grep sys_sendmsg >>> ffffffff803e9ac5 T sys_sendmsg >>> >>> >>> // Starting gdb on host and setting a breakpoint: >>> >>> $ gdb vmlinux >>> >>> GNU gdb 6.6.50.20070726-cvs >>> Copyright (C) 2007 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public >> License, and >>> you are welcome to change it and/or distribute copies of it under >>> certain conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for >>> details. >>> This GDB was configured as "x86_64-suse-linux"... >>> Using host libthread_db library "/lib64/libthread_db.so.1". >>> (gdb) l sys_sendmsg >>> 1783 /* >>> 1784 * BSD sendmsg interface >>> 1785 */ >>> 1786 >>> 1787 asmlinkage long sys_sendmsg(int fd, struct msghdr >> __user *msg, >>> unsigned flags) >>> 1788 { >>> 1789 struct compat_msghdr __user *msg_compat = >>> 1790 (struct compat_msghdr __user *)msg; >>> 1791 struct socket *sock; >>> 1792 char address[MAX_SOCK_ADDR]; >>> (gdb) b 1787 >>> Breakpoint 1 at 0xffffffff803e9ac5: file net/socket.c, line 1787. >>> (gdb) >>> >>> // Now connect to qemu's gdb-stub: >>> >>> (gdb) target remote :1234 >>> Remote debugging using :1234 >>> 0x0000000000000000 in ?? () >>> (gdb) c >>> Continuing. >>> >>> // On guest launching a ping for example, to trigger the breakpoint: >>> >>> $ ping 212.76.144.43 >>> >>> // On Host gdb stops, but it looks strange no address info etc is >>> shown?!?! >>> >>> Program received signal SIGTRAP, Trace/breakpoint trap. >>> 0x0000000000000000 in ?? () >> Make sure gdb is assuming the right arch at this point (=> >> set arch i386:x86-64). If you initially break into the guest >> when it is still in real mode, gdb stays in i386 mode even if >> the guest's mode changes. >> >> Jan >> > > Hello Jan, > thanks for your reply! > I've tried your suggestion with "set arch i386:x86-64" > But it seems that it has no effect on this problem. But it was a good > idea. > > Additionally I've tried all architectures just to see what happens. > > This is what ive done: > > (gdb) set architecture i386:x86-64 > The target architecture is assumed to be i386:x86-64 > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x0000000000000000 in ?? () > (gdb) s > Cannot find bounds of current function > (gdb) n > Cannot find bounds of current function > (gdb) info locals > No symbol table info available. > (gdb) set architecture i386 > The target architecture is assumed to be i386 > (gdb) c > Continuing. > > // > > Program received signal SIGINT, Interrupt. > 0x8020aed9 in ?? () > (gdb) p this > No symbol "this" in current context. > (gdb) info locals > No symbol table info available. > (gdb) l *0x8020aed9 > No source file for address 0x8020aed9. > (gdb) p *0x8020aed9 > Cannot access memory at address 0x8020aed9 > (gdb) set architecture i386:intel > The target architecture is assumed to be i386:intel > (gdb) c > Continuing. > > // > > Program received signal SIGINT, Interrupt. > 0x8020aed9 in ?? () > (gdb) p this > No symbol "this" in current context. > (gdb) info locals > No symbol table info available. > (gdb) s > Cannot find bounds of current function > (gdb) n > Cannot find bounds of current function > (gdb) l *0x8020aed9 > No source file for address 0x8020aed9. > (gdb) set architecture i386:x86-64:intel > The target architecture is assumed to be i386:x86-64:intel > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x0000000000000000 in ?? () > (gdb) info locals > No symbol table info available. > (gdb) n > Cannot find bounds of current function > (gdb) s > Cannot find bounds of current function > (gdb) p this > No symbol "this" in current context. > (gdb) set architecture i8086 > The target architecture is assumed to be i8086 > (gdb) c > Continuing. > > // > > Program received signal SIGINT, Interrupt. > 0x8020aed9 in ?? () > (gdb) s > Cannot find bounds of current function > (gdb) n > Cannot find bounds of current function > (gdb) info locals > No symbol table info available. > (gdb) set architecture > auto i386:intel i386:x86-64:intel > i386 i386:x86-64 i8086 > (gdb) set architecture auto > The target architecture is set automatically (currently i386:x86-64) > (gdb) > > Any further ideas what is going / I'm doing wrong ? Missed breakpoints most often mean that the executed image and the one loaded by gdb do not match. Try comparing offline and runtime disassemblies of the same locations. Jan