[Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Keilhau Timo ( Student )]

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 ?? ()
(gdb) info locals
No symbol table info available.
(gdb) info source
Current source file is net/socket.c
Compilation directory is /usr/src/linux
Located in /home/keilhaut/kernel_qemu/linux-2.6.25/net/socket.c
Contains 2356 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
(gdb) info breakpoints
Num Type           Disp Enb Address            What
1   breakpoint     keep y   0xffffffff803e9ac5 in sys_sendmsg at
net/socket.c:1787
(gdb) disable 1
(gdb) c
Continuing.

// Looking up the address on guest (the address is exactly the same!):

$ cat /proc/kallsyms | grep sys_sendmsg
ffffffff803e9ac5 T sys_sendmsg

// another attemp enabling the last breakpoint and launching the ping
again:
...

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000000000 in ?? ()
(gdb) set debug remote 1
(gdb) p *this
No symbol "this" in current context.
(gdb) bt
#0  0x0000000000000000 in ?? ()
Sending packet: $m0,8#01...Ack
Packet received: E14
Cannot access memory at address 0x0
(gdb) info registers
rax            0x2e     46
rbx            0x0      0
rcx            0x40050c9f80     274962620288
rdx            0x300507920      12890175776
rsi            0x297803e9ac5    2849714903749
rdi            0x1800000010     103079215120
rbp            0x0      0x0
rsp            0x0      0x0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0x0      0
eflags         0x8000000        [ #27 ]
cs             0x4019cd58       1075432792
ss             0x37f    895
ds             0x3800   14336
es             0x0      0
fs             0x0      0
gs             0x0      0
fctrl          0x0      0
fstat          0x0      0
ftag           0x0      0
fiseg          0x0      0
fioff          0x0      0
foseg          0x0      0
fooff          0x0      0
fop            0x0      0
mxcsr          0x0      [ ]
(gdb) step
Cannot find bounds of current function
(gdb) next
Cannot find bounds of current function
(gdb) quit
The program is running.  Exit anyway? (y or n) y
Sending packet: $k#6b...Ack


"info reg" is the only command that I can use to get information from
guest.
I cant inspect variables, cant step etc etc...
Ive read many howtos and faqs. But ive found no solution to this
problem.
Maybe Ive missed something to do?!
Ive compiled the 2.6.25 kernel on guest with:
 [*] Compile the kernel with frame pointers
 [*] Compile the kernel with debug info
additionally CFLAGS="-g3 -ggdb"

Does somebody have had same problems?
Does somebody have an idea what else I can try?

I am glad for any help!!

Thanks, timo

[Qemu-devel] Re: Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Jan Kiszka]

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

RE: [Qemu-devel] Re: Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Keilhau Timo ( Student )]

 

> -----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.

// <manual break here because gdb diddn't automatically>

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.

// <manual break here because gdb diddn't automatically>

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.

// <manual break here because gdb diddn't automatically>

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 ?

Re: [Qemu-devel] Re: Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 6564 bytes --]

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.
> 
> // <manual break here because gdb diddn't automatically>
> 
> 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.
> 
> // <manual break here because gdb diddn't automatically>
> 
> 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.
> 
> // <manual break here because gdb diddn't automatically>
> 
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Mulyadi Santosa]

Hi...

On Thu, May 8, 2008 at 2:53 PM, Keilhau Timo ( Student )
<timo.keilhau.student@thomson.net> wrote:
> Ive compiled the 2.6.25 kernel on guest with:
>  [*] Compile the kernel with frame pointers
>  [*] Compile the kernel with debug info
> additionally CFLAGS="-g3 -ggdb"

You meant -O3? well, IMO, you don't need -O at all. AFAIK mixing -g or
-ggdb with -O{1,2,3} is a bad thing, since it will render the DWARF
information inside the ELF file (in this case, the vmlinux)
inconsistent with the runtime context (line number, current EIP
correlated with break points).

Of course, this assume that there is no bugs while Qemu inspect and
found that it must pause at certain address... I believe Jasson Wessel
had squashed all that kind of bugs in the past.

regards,

Mulyadi.

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Jason Wessel]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

Mulyadi Santosa wrote:
> Hi...
>
> On Thu, May 8, 2008 at 2:53 PM, Keilhau Timo ( Student )
> <timo.keilhau.student@thomson.net> wrote:
>   
>> Ive compiled the 2.6.25 kernel on guest with:
>>  [*] Compile the kernel with frame pointers
>>  [*] Compile the kernel with debug info
>> additionally CFLAGS="-g3 -ggdb"
>>     
>
> You meant -O3? well, IMO, you don't need -O at all. AFAIK mixing -g or
> -ggdb with -O{1,2,3} is a bad thing, since it will render the DWARF
> information inside the ELF file (in this case, the vmlinux)
> inconsistent with the runtime context (line number, current EIP
> correlated with break points).
>
> Of course, this assume that there is no bugs while Qemu inspect and
> found that it must pause at certain address... I believe Jasson Wessel
> had squashed all that kind of bugs in the past.
>
> regards,
>
> Mulyadi.
>
>   
I believe that Mulyadi is talking about the following two patches which
are attached here, assuming you are able to hit breakpoints.

Jason.


[-- Attachment #2: x86-64_gdb.patch --]
[-- Type: text/x-patch, Size: 4428 bytes --]

From: Jason Wessel <jason.wessel@windriver.com>
Subject: [PATCH] Add x86_64 gdb stub for qemu

This patch comes from the kvm sources and allows debugging the back
end with gdb connected to qemu for the qemu-system-x86_64 machine.


Signed-off-by: Jason Wessel <jason.wessel@windriver.com>


---
 gdbstub.c |  134 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 133 insertions(+), 1 deletion(-)

--- a/gdbstub.c
+++ b/gdbstub.c
@@ -238,9 +238,141 @@ static int put_packet(GDBState *s, char 
     }
     return 0;
 }
+#if defined(TARGET_X86_64)
 
-#if defined(TARGET_I386)
+static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
+{
+    uint8_t *p = mem_buf;
+    int i, fpus;
+
+#define PUTREG(x) do { \
+       target_ulong reg = tswapl(x); \
+       memcpy(p, &reg, sizeof reg); \
+       p += sizeof reg; \
+    } while (0)
+#define PUTREG32(x) do { \
+       uint32_t reg = tswap32(x);              \
+       memcpy(p, &reg, sizeof reg); \
+       p += sizeof reg; \
+    } while (0)
+#define PUTREGF(x) do { \
+       memcpy(p, &(x), 10);                     \
+       p += sizeof (x);                     \
+    } while (0)
+
+    PUTREG(env->regs[R_EAX]);
+    PUTREG(env->regs[R_EBX]);
+    PUTREG(env->regs[R_ECX]);
+    PUTREG(env->regs[R_EDX]);
+    PUTREG(env->regs[R_ESI]);
+    PUTREG(env->regs[R_EDI]);
+    PUTREG(env->regs[R_EBP]);
+    PUTREG(env->regs[R_ESP]);
+    PUTREG(env->regs[8]);
+    PUTREG(env->regs[9]);
+    PUTREG(env->regs[10]);
+    PUTREG(env->regs[11]);
+    PUTREG(env->regs[12]);
+    PUTREG(env->regs[13]);
+    PUTREG(env->regs[14]);
+    PUTREG(env->regs[15]);
+
+    PUTREG(env->eip);
+    PUTREG32(env->eflags);
+    PUTREG32(env->segs[R_CS].selector);
+    PUTREG32(env->segs[R_SS].selector);
+    PUTREG32(env->segs[R_DS].selector);
+    PUTREG32(env->segs[R_ES].selector);
+    PUTREG32(env->segs[R_FS].selector);
+    PUTREG32(env->segs[R_GS].selector);
+    /* XXX: convert floats */
+    for(i = 0; i < 8; i++) {
+        PUTREGF(env->fpregs[i]);
+    }
+    PUTREG32(env->fpuc);
+    fpus = (env->fpus & ~0x3800) | (env->fpstt & 0x7) << 11;
+    PUTREG32(fpus);
+    PUTREG32(0); /* XXX: convert tags */
+    PUTREG32(0); /* fiseg */
+    PUTREG32(0); /* fioff */
+    PUTREG32(0); /* foseg */
+    PUTREG32(0); /* fooff */
+    PUTREG32(0); /* fop */
+
+#undef PUTREG
+#undef PUTREG32
+#undef PUTREGF
+
+    return p - mem_buf;
+}
+
+static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int size)
+{
+    uint8_t *p = mem_buf;
+    uint32_t junk;
+    int i, fpus;
+
+#define GETREG(x) do { \
+       target_ulong reg; \
+       memcpy(&reg, p, sizeof reg);     \
+       x = tswapl(reg);               \
+       p += sizeof reg;                 \
+    } while (0)
+#define GETREG32(x) do { \
+       uint32_t reg; \
+       memcpy(&reg, p, sizeof reg);     \
+       x = tswap32(reg);               \
+       p += sizeof reg;                 \
+    } while (0)
+#define GETREGF(x) do { \
+       memcpy(&(x), p, 10);               \
+       p += 10;                         \
+    } while (0)
+
+    GETREG(env->regs[R_EAX]);
+    GETREG(env->regs[R_EBX]);
+    GETREG(env->regs[R_ECX]);
+    GETREG(env->regs[R_EDX]);
+    GETREG(env->regs[R_ESI]);
+    GETREG(env->regs[R_EDI]);
+    GETREG(env->regs[R_EBP]);
+    GETREG(env->regs[R_ESP]);
+    GETREG(env->regs[8]);
+    GETREG(env->regs[9]);
+    GETREG(env->regs[10]);
+    GETREG(env->regs[11]);
+    GETREG(env->regs[12]);
+    GETREG(env->regs[13]);
+    GETREG(env->regs[14]);
+    GETREG(env->regs[15]);
+
+    GETREG(env->eip);
+    GETREG32(env->eflags);
+    GETREG32(env->segs[R_CS].selector);
+    GETREG32(env->segs[R_SS].selector);
+    GETREG32(env->segs[R_DS].selector);
+    GETREG32(env->segs[R_ES].selector);
+    GETREG32(env->segs[R_FS].selector);
+    GETREG32(env->segs[R_GS].selector);
+    /* XXX: convert floats */
+    for(i = 0; i < 8; i++) {
+        GETREGF(env->fpregs[i]);
+    }
+    GETREG32(env->fpuc);
+    GETREG32(fpus); /* XXX: convert fpus */
+    GETREG32(junk); /* XXX: convert tags */
+    GETREG32(junk); /* fiseg */
+    GETREG32(junk); /* fioff */
+    GETREG32(junk); /* foseg */
+    GETREG32(junk); /* fooff */
+    GETREG32(junk); /* fop */
+
+#undef GETREG
+#undef GETREG32
+#undef GETREGF
+}
 
+#elif defined(TARGET_I386)
 static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
 {
     int i, fpus;

[-- Attachment #3: single_step_noirq_notimer.patch --]
[-- Type: text/x-patch, Size: 6104 bytes --]

From: Jason Wessel <jason.wessel@windriver.com>
Subject: [PATCH] debugger single step without interrupts

This patch allows the qemu backend debugger to single step an
instruction without running the hardware interrupts.


Signed-off-by: Jason Wessel <jason.wessel@windriver.com>

---
 cpu-all.h     |    5 +++++
 cpu-exec.c    |    2 +-
 gdbstub.c     |   39 ++++++++++++++++++++++++++++++++++-----
 qemu-doc.texi |   30 ++++++++++++++++++++++++++++++
 vl.c          |    2 ++
 5 files changed, 72 insertions(+), 6 deletions(-)

--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -422,7 +422,7 @@ int cpu_exec(CPUState *env1)
 #if defined(TARGET_I386)
 			&& env->hflags & HF_GIF_MASK
 #endif
-				) {
+            && !(env->singlestep_enabled & SSTEP_NOIRQ)) {
                     if (interrupt_request & CPU_INTERRUPT_DEBUG) {
                         env->interrupt_request &= ~CPU_INTERRUPT_DEBUG;
                         env->exception_index = EXCP_DEBUG;
--- a/vl.c
+++ b/vl.c
@@ -7508,6 +7508,7 @@ void main_loop_wait(int timeout)
     qemu_aio_poll();
 
     if (vm_running) {
+        if (!(cur_cpu->singlestep_enabled & SSTEP_NOTIMER))
         qemu_run_timers(&active_timers[QEMU_TIMER_VIRTUAL],
                         qemu_get_clock(vm_clock));
         /* run dma transfers, if any */
@@ -7515,6 +7516,7 @@ void main_loop_wait(int timeout)
     }
 
     /* real time timers */
+    if (!(cur_cpu->singlestep_enabled & SSTEP_NOTIMER))
     qemu_run_timers(&active_timers[QEMU_TIMER_REALTIME],
                     qemu_get_clock(rt_clock));
 
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -73,6 +73,11 @@ typedef struct GDBState {
 #endif
 } GDBState;
 
+/* By default use no IRQs and no timers while single stepping so as to
+ * make single stepping like an ICE HW step.
+ */
+static int sstep_flags = SSTEP_ENABLE|SSTEP_NOIRQ|SSTEP_NOTIMER;
+
 #ifdef CONFIG_USER_ONLY
 /* XXX: This is not thread safe.  Do we care?  */
 static int gdbserver_fd = -1;
@@ -940,7 +945,7 @@ static int gdb_handle_packet(GDBState *s
             env->pc = addr;
 #endif
         }
-        cpu_single_step(env, 1);
+        cpu_single_step(env, sstep_flags);
         gdb_continue(s);
 	return RS_IDLE;
     case 'F':
@@ -1047,9 +1052,34 @@ static int gdb_handle_packet(GDBState *s
             goto breakpoint_error;
         }
         break;
-#ifdef CONFIG_LINUX_USER
     case 'q':
-        if (strncmp(p, "Offsets", 7) == 0) {
+    case 'Q':
+        /* parse any 'q' packets here */
+        if (!strcmp(p,"qemu.sstepbits")) {
+            /* Query Breakpoint bit definitions */
+            sprintf(buf,"ENABLE=%x,NOIRQ=%x,NOTIMER=%x",
+                    SSTEP_ENABLE,
+                    SSTEP_NOIRQ,
+                    SSTEP_NOTIMER);
+            put_packet(s, buf);
+            break;
+        } else if (strncmp(p,"qemu.sstep",10) == 0) {
+            /* Display or change the sstep_flags */
+            p += 10;
+            if (*p != '=') {
+                /* Display current setting */
+                sprintf(buf,"0x%x", sstep_flags);
+                put_packet(s, buf);
+                break;
+            }
+            p++;
+            type = strtoul(p, (char **)&p, 16);
+            sstep_flags = type;
+            put_packet(s, "OK");
+            break;
+        }
+#ifdef CONFIG_LINUX_USER
+        else if (strncmp(p, "Offsets", 7) == 0) {
             TaskState *ts = env->opaque;
 
             sprintf(buf,
@@ -1061,10 +1091,9 @@ static int gdb_handle_packet(GDBState *s
             put_packet(s, buf);
             break;
         }
-        /* Fall through.  */
 #endif
+        /* Fall through.  */
     default:
-        //        unknown_command:
         /* put empty packet */
         buf[0] = '\0';
         put_packet(s, buf);
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -761,6 +761,11 @@ int cpu_watchpoint_insert(CPUState *env,
 int cpu_watchpoint_remove(CPUState *env, target_ulong addr);
 int cpu_breakpoint_insert(CPUState *env, target_ulong pc);
 int cpu_breakpoint_remove(CPUState *env, target_ulong pc);
+
+#define SSTEP_ENABLE  0x1  /* Enable simulated HW single stepping */
+#define SSTEP_NOIRQ   0x2  /* Do not use IRQ while single stepping */
+#define SSTEP_NOTIMER 0x4  /* Do not Timers while single stepping */
+
 void cpu_single_step(CPUState *env, int enabled);
 void cpu_reset(CPUState *s);
 
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -1924,6 +1924,36 @@ Use @code{set architecture i8086} to dum
 @code{x/10i $cs*16+$eip} to dump the code at the PC position.
 @end enumerate
 
+Advanced debugging options:
+
+The default single stepping behavior is step with the IRQs and timer service routines off.  It is set this way because when gdb executes a single step it expects to advance beyond the current instruction.  With the IRQs and and timer service routines on, a single step might jump into the one of the interrupt or exception vectors instead of executing the current instruction. This means you may hit the same breakpoint a number of times before executing the instruction gdb wants to have executed.  Because there are rare circumstances where you want to single step into an interrupt vector the behavior can be controlled from GDB.  There are three commands you can query and set the single step behavior:
+@enumerate @code
+@item maintenance packet qqemu.sstepbits
+
+This will display the MASK bits used to control the single stepping IE:
+@example
+(gdb) maintenance packet qqemu.sstepbits
+sending: "qqemu.sstepbits"
+received: "ENABLE=1,NOIRQ=2,NOTIMER=4"
+@end example
+@item maintenance packet qqemu.sstep
+
+This will display the current value of the mask used when single stepping IE:
+@example
+(gdb) maintenance packet qqemu.sstep
+sending: "qqemu.sstep"
+received: "0x7"
+@end example
+@item maintenance packet Qqemu.sstep=HEX_VALUE
+
+This will change the single step mask, so if wanted to enable IRQs on the single step, but not timers, you would use:
+@example
+(gdb) maintenance packet Qqemu.sstep=0x5
+sending: "qemu.sstep=0x5"
+received: "OK"
+@end example
+@end enumerate
+
 @node pcsys_os_specific
 @section Target OS specific information
 

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Mulyadi Santosa]

HI Jason...

On Fri, May 9, 2008 at 11:39 AM, Jason Wessel
<jason.wessel@windriver.com> wrote:
>> Of course, this assume that there is no bugs while Qemu inspect and
>> found that it must pause at certain address... I believe Jasson Wessel
>> had squashed all that kind of bugs in the past.
>>
>> regards,
>>
>> Mulyadi.
>>
>>
> I believe that Mulyadi is talking about the following two patches which
> are attached here, assuming you are able to hit breakpoints.

Thanks.... I believe that's the patch that will fix his problem.

regards,

Mulyadi.

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Jan Kiszka]

Mulyadi Santosa wrote:
> HI Jason...
> 
> On Fri, May 9, 2008 at 11:39 AM, Jason Wessel
> <jason.wessel@windriver.com> wrote:
>>> Of course, this assume that there is no bugs while Qemu inspect and
>>> found that it must pause at certain address... I believe Jasson Wessel
>>> had squashed all that kind of bugs in the past.
>>>
>>> regards,
>>>
>>> Mulyadi.
>>>
>>>
>> I believe that Mulyadi is talking about the following two patches which
>> are attached here, assuming you are able to hit breakpoints.
> 
> Thanks.... I believe that's the patch that will fix his problem.

I'm not /that/ sure. The second one affects single stepping only, and
the first one is now redundant as QEMU (and thus also KVM) uses a
compacter way of supporting x86-64 registers. But maybe the patch is
still required for "old" QEMU 0.9.1 (I'm working with development heads
only). But IIRC, the error pattern used to be quite different when QEMU
did not yet support x86-64 registers.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Edgar E. Iglesias]

On Thu, May 08, 2008 at 11:39:11PM -0500, Jason Wessel wrote:
> Mulyadi Santosa wrote:
> > Hi...
> >
> > On Thu, May 8, 2008 at 2:53 PM, Keilhau Timo ( Student )
> > <timo.keilhau.student@thomson.net> wrote:
> >   
> >> Ive compiled the 2.6.25 kernel on guest with:
> >>  [*] Compile the kernel with frame pointers
> >>  [*] Compile the kernel with debug info
> >> additionally CFLAGS="-g3 -ggdb"
> >>     
> >
> > You meant -O3? well, IMO, you don't need -O at all. AFAIK mixing -g or
> > -ggdb with -O{1,2,3} is a bad thing, since it will render the DWARF
> > information inside the ELF file (in this case, the vmlinux)
> > inconsistent with the runtime context (line number, current EIP
> > correlated with break points).
> >
> > Of course, this assume that there is no bugs while Qemu inspect and
> > found that it must pause at certain address... I believe Jasson Wessel
> > had squashed all that kind of bugs in the past.
> >
> > regards,
> >
> > Mulyadi.
> >
> >   
> I believe that Mulyadi is talking about the following two patches which
> are attached here, assuming you are able to hit breakpoints.
> 
> Jason.
> 

Hi,

Tested the singlestepping w/o interrupts, it works very nice thanks.

Best regards


> From: Jason Wessel <jason.wessel@windriver.com>
> Subject: [PATCH] Add x86_64 gdb stub for qemu
> 
> This patch comes from the kvm sources and allows debugging the back
> end with gdb connected to qemu for the qemu-system-x86_64 machine.
> 
> 
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> 
> 
> ---
>  gdbstub.c |  134 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 133 insertions(+), 1 deletion(-)
> 
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -238,9 +238,141 @@ static int put_packet(GDBState *s, char 
>      }
>      return 0;
>  }
> +#if defined(TARGET_X86_64)
>  
> -#if defined(TARGET_I386)
> +static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
> +{
> +    uint8_t *p = mem_buf;
> +    int i, fpus;
> +
> +#define PUTREG(x) do { \
> +       target_ulong reg = tswapl(x); \
> +       memcpy(p, &reg, sizeof reg); \
> +       p += sizeof reg; \
> +    } while (0)
> +#define PUTREG32(x) do { \
> +       uint32_t reg = tswap32(x);              \
> +       memcpy(p, &reg, sizeof reg); \
> +       p += sizeof reg; \
> +    } while (0)
> +#define PUTREGF(x) do { \
> +       memcpy(p, &(x), 10);                     \
> +       p += sizeof (x);                     \
> +    } while (0)
> +
> +    PUTREG(env->regs[R_EAX]);
> +    PUTREG(env->regs[R_EBX]);
> +    PUTREG(env->regs[R_ECX]);
> +    PUTREG(env->regs[R_EDX]);
> +    PUTREG(env->regs[R_ESI]);
> +    PUTREG(env->regs[R_EDI]);
> +    PUTREG(env->regs[R_EBP]);
> +    PUTREG(env->regs[R_ESP]);
> +    PUTREG(env->regs[8]);
> +    PUTREG(env->regs[9]);
> +    PUTREG(env->regs[10]);
> +    PUTREG(env->regs[11]);
> +    PUTREG(env->regs[12]);
> +    PUTREG(env->regs[13]);
> +    PUTREG(env->regs[14]);
> +    PUTREG(env->regs[15]);
> +
> +    PUTREG(env->eip);
> +    PUTREG32(env->eflags);
> +    PUTREG32(env->segs[R_CS].selector);
> +    PUTREG32(env->segs[R_SS].selector);
> +    PUTREG32(env->segs[R_DS].selector);
> +    PUTREG32(env->segs[R_ES].selector);
> +    PUTREG32(env->segs[R_FS].selector);
> +    PUTREG32(env->segs[R_GS].selector);
> +    /* XXX: convert floats */
> +    for(i = 0; i < 8; i++) {
> +        PUTREGF(env->fpregs[i]);
> +    }
> +    PUTREG32(env->fpuc);
> +    fpus = (env->fpus & ~0x3800) | (env->fpstt & 0x7) << 11;
> +    PUTREG32(fpus);
> +    PUTREG32(0); /* XXX: convert tags */
> +    PUTREG32(0); /* fiseg */
> +    PUTREG32(0); /* fioff */
> +    PUTREG32(0); /* foseg */
> +    PUTREG32(0); /* fooff */
> +    PUTREG32(0); /* fop */
> +
> +#undef PUTREG
> +#undef PUTREG32
> +#undef PUTREGF
> +
> +    return p - mem_buf;
> +}
> +
> +static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int size)
> +{
> +    uint8_t *p = mem_buf;
> +    uint32_t junk;
> +    int i, fpus;
> +
> +#define GETREG(x) do { \
> +       target_ulong reg; \
> +       memcpy(&reg, p, sizeof reg);     \
> +       x = tswapl(reg);               \
> +       p += sizeof reg;                 \
> +    } while (0)
> +#define GETREG32(x) do { \
> +       uint32_t reg; \
> +       memcpy(&reg, p, sizeof reg);     \
> +       x = tswap32(reg);               \
> +       p += sizeof reg;                 \
> +    } while (0)
> +#define GETREGF(x) do { \
> +       memcpy(&(x), p, 10);               \
> +       p += 10;                         \
> +    } while (0)
> +
> +    GETREG(env->regs[R_EAX]);
> +    GETREG(env->regs[R_EBX]);
> +    GETREG(env->regs[R_ECX]);
> +    GETREG(env->regs[R_EDX]);
> +    GETREG(env->regs[R_ESI]);
> +    GETREG(env->regs[R_EDI]);
> +    GETREG(env->regs[R_EBP]);
> +    GETREG(env->regs[R_ESP]);
> +    GETREG(env->regs[8]);
> +    GETREG(env->regs[9]);
> +    GETREG(env->regs[10]);
> +    GETREG(env->regs[11]);
> +    GETREG(env->regs[12]);
> +    GETREG(env->regs[13]);
> +    GETREG(env->regs[14]);
> +    GETREG(env->regs[15]);
> +
> +    GETREG(env->eip);
> +    GETREG32(env->eflags);
> +    GETREG32(env->segs[R_CS].selector);
> +    GETREG32(env->segs[R_SS].selector);
> +    GETREG32(env->segs[R_DS].selector);
> +    GETREG32(env->segs[R_ES].selector);
> +    GETREG32(env->segs[R_FS].selector);
> +    GETREG32(env->segs[R_GS].selector);
> +    /* XXX: convert floats */
> +    for(i = 0; i < 8; i++) {
> +        GETREGF(env->fpregs[i]);
> +    }
> +    GETREG32(env->fpuc);
> +    GETREG32(fpus); /* XXX: convert fpus */
> +    GETREG32(junk); /* XXX: convert tags */
> +    GETREG32(junk); /* fiseg */
> +    GETREG32(junk); /* fioff */
> +    GETREG32(junk); /* foseg */
> +    GETREG32(junk); /* fooff */
> +    GETREG32(junk); /* fop */
> +
> +#undef GETREG
> +#undef GETREG32
> +#undef GETREGF
> +}
>  
> +#elif defined(TARGET_I386)
>  static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
>  {
>      int i, fpus;

> From: Jason Wessel <jason.wessel@windriver.com>
> Subject: [PATCH] debugger single step without interrupts
> 
> This patch allows the qemu backend debugger to single step an
> instruction without running the hardware interrupts.
> 
> 
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> 
> ---
>  cpu-all.h     |    5 +++++
>  cpu-exec.c    |    2 +-
>  gdbstub.c     |   39 ++++++++++++++++++++++++++++++++++-----
>  qemu-doc.texi |   30 ++++++++++++++++++++++++++++++
>  vl.c          |    2 ++
>  5 files changed, 72 insertions(+), 6 deletions(-)
> 
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -422,7 +422,7 @@ int cpu_exec(CPUState *env1)
>  #if defined(TARGET_I386)
>  			&& env->hflags & HF_GIF_MASK
>  #endif
> -				) {
> +            && !(env->singlestep_enabled & SSTEP_NOIRQ)) {
>                      if (interrupt_request & CPU_INTERRUPT_DEBUG) {
>                          env->interrupt_request &= ~CPU_INTERRUPT_DEBUG;
>                          env->exception_index = EXCP_DEBUG;
> --- a/vl.c
> +++ b/vl.c
> @@ -7508,6 +7508,7 @@ void main_loop_wait(int timeout)
>      qemu_aio_poll();
>  
>      if (vm_running) {
> +        if (!(cur_cpu->singlestep_enabled & SSTEP_NOTIMER))
>          qemu_run_timers(&active_timers[QEMU_TIMER_VIRTUAL],
>                          qemu_get_clock(vm_clock));
>          /* run dma transfers, if any */
> @@ -7515,6 +7516,7 @@ void main_loop_wait(int timeout)
>      }
>  
>      /* real time timers */
> +    if (!(cur_cpu->singlestep_enabled & SSTEP_NOTIMER))
>      qemu_run_timers(&active_timers[QEMU_TIMER_REALTIME],
>                      qemu_get_clock(rt_clock));
>  
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -73,6 +73,11 @@ typedef struct GDBState {
>  #endif
>  } GDBState;
>  
> +/* By default use no IRQs and no timers while single stepping so as to
> + * make single stepping like an ICE HW step.
> + */
> +static int sstep_flags = SSTEP_ENABLE|SSTEP_NOIRQ|SSTEP_NOTIMER;
> +
>  #ifdef CONFIG_USER_ONLY
>  /* XXX: This is not thread safe.  Do we care?  */
>  static int gdbserver_fd = -1;
> @@ -940,7 +945,7 @@ static int gdb_handle_packet(GDBState *s
>              env->pc = addr;
>  #endif
>          }
> -        cpu_single_step(env, 1);
> +        cpu_single_step(env, sstep_flags);
>          gdb_continue(s);
>  	return RS_IDLE;
>      case 'F':
> @@ -1047,9 +1052,34 @@ static int gdb_handle_packet(GDBState *s
>              goto breakpoint_error;
>          }
>          break;
> -#ifdef CONFIG_LINUX_USER
>      case 'q':
> -        if (strncmp(p, "Offsets", 7) == 0) {
> +    case 'Q':
> +        /* parse any 'q' packets here */
> +        if (!strcmp(p,"qemu.sstepbits")) {
> +            /* Query Breakpoint bit definitions */
> +            sprintf(buf,"ENABLE=%x,NOIRQ=%x,NOTIMER=%x",
> +                    SSTEP_ENABLE,
> +                    SSTEP_NOIRQ,
> +                    SSTEP_NOTIMER);
> +            put_packet(s, buf);
> +            break;
> +        } else if (strncmp(p,"qemu.sstep",10) == 0) {
> +            /* Display or change the sstep_flags */
> +            p += 10;
> +            if (*p != '=') {
> +                /* Display current setting */
> +                sprintf(buf,"0x%x", sstep_flags);
> +                put_packet(s, buf);
> +                break;
> +            }
> +            p++;
> +            type = strtoul(p, (char **)&p, 16);
> +            sstep_flags = type;
> +            put_packet(s, "OK");
> +            break;
> +        }
> +#ifdef CONFIG_LINUX_USER
> +        else if (strncmp(p, "Offsets", 7) == 0) {
>              TaskState *ts = env->opaque;
>  
>              sprintf(buf,
> @@ -1061,10 +1091,9 @@ static int gdb_handle_packet(GDBState *s
>              put_packet(s, buf);
>              break;
>          }
> -        /* Fall through.  */
>  #endif
> +        /* Fall through.  */
>      default:
> -        //        unknown_command:
>          /* put empty packet */
>          buf[0] = '\0';
>          put_packet(s, buf);
> --- a/cpu-all.h
> +++ b/cpu-all.h
> @@ -761,6 +761,11 @@ int cpu_watchpoint_insert(CPUState *env,
>  int cpu_watchpoint_remove(CPUState *env, target_ulong addr);
>  int cpu_breakpoint_insert(CPUState *env, target_ulong pc);
>  int cpu_breakpoint_remove(CPUState *env, target_ulong pc);
> +
> +#define SSTEP_ENABLE  0x1  /* Enable simulated HW single stepping */
> +#define SSTEP_NOIRQ   0x2  /* Do not use IRQ while single stepping */
> +#define SSTEP_NOTIMER 0x4  /* Do not Timers while single stepping */
> +
>  void cpu_single_step(CPUState *env, int enabled);
>  void cpu_reset(CPUState *s);
>  
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -1924,6 +1924,36 @@ Use @code{set architecture i8086} to dum
>  @code{x/10i $cs*16+$eip} to dump the code at the PC position.
>  @end enumerate
>  
> +Advanced debugging options:
> +
> +The default single stepping behavior is step with the IRQs and timer service routines off.  It is set this way because when gdb executes a single step it expects to advance beyond the current instruction.  With the IRQs and and timer service routines on, a single step might jump into the one of the interrupt or exception vectors instead of executing the current instruction. This means you may hit the same breakpoint a number of times before executing the instruction gdb wants to have executed.  Because there are rare circumstances where you want to single step into an interrupt vector the behavior can be controlled from GDB.  There are three commands you can query and set the single step behavior:
> +@enumerate @code
> +@item maintenance packet qqemu.sstepbits
> +
> +This will display the MASK bits used to control the single stepping IE:
> +@example
> +(gdb) maintenance packet qqemu.sstepbits
> +sending: "qqemu.sstepbits"
> +received: "ENABLE=1,NOIRQ=2,NOTIMER=4"
> +@end example
> +@item maintenance packet qqemu.sstep
> +
> +This will display the current value of the mask used when single stepping IE:
> +@example
> +(gdb) maintenance packet qqemu.sstep
> +sending: "qqemu.sstep"
> +received: "0x7"
> +@end example
> +@item maintenance packet Qqemu.sstep=HEX_VALUE
> +
> +This will change the single step mask, so if wanted to enable IRQs on the single step, but not timers, you would use:
> +@example
> +(gdb) maintenance packet Qqemu.sstep=0x5
> +sending: "qemu.sstep=0x5"
> +received: "OK"
> +@end example
> +@end enumerate
> +
>  @node pcsys_os_specific
>  @section Target OS specific information
>  


-- 
Edgar E. Iglesias
Axis Communications AB

RE: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Keilhau Timo ( Student )]

 

> -----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 Mulyadi Santosa
> Sent: Freitag, 9. Mai 2008 09:24
> To: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] Debugging vmlinux with qemu and 
> gdb. Unable to step,next, print or to get any information..
> 
> HI Jason...
> 
> On Fri, May 9, 2008 at 11:39 AM, Jason Wessel 
> <jason.wessel@windriver.com> wrote:
> >> Of course, this assume that there is no bugs while Qemu 
> inspect and 
> >> found that it must pause at certain address... I believe Jasson 
> >> Wessel had squashed all that kind of bugs in the past.
> >>
> >> regards,
> >>
> >> Mulyadi.
> >>
> >>
> > I believe that Mulyadi is talking about the following two patches 
> > which are attached here, assuming you are able to hit breakpoints.
> 
> Thanks.... I believe that's the patch that will fix his problem.
> 
> regards,
> 
> Mulyadi.
> 

Hello Jan, Jason and Mulyadi!
BIG BIG thanks to you! It works now!
You really have pointed me to the right solution.

First Ive tried to compile qemu 0.9.1 from source with your patches
applied.
But it failed cause I have gcc version 4.2.1 installed and qemu needs
version 3.x.x
Then Ive tried to compile gcc 3.4.6 but with no success make throws
errors i havn't get managed...

But anyways I've downloaded a newer qemu version from rpmfind.net:
ftp://fr2.rpmfind.net/linux/opensuse/distribution/SL-OSS-factory/inst-so
urce/suse/x86_64/qemu-0.9.1-40.x86_64.rpm
Updated my rpm package to version: rpm-4.4.2-192.x86_64

And now all things like addressinfo and stepping working like expected:

GDB TEST----------------------------------------------->>

(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) c
Continuing.

Breakpoint 1, sys_sendmsg (fd=3, msg=0x507920, flags=0) at
net/socket.c:1788
1788    {
(gdb) bt
#0  sys_sendmsg (fd=3, msg=0x507920, flags=0) at net/socket.c:1788
#1  0xffffffff8020be9b in system_call ()
#2  0x0000000000000246 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) s
0xffffffff8020ca85 in apic_timer_interrupt ()
(gdb) s
Single stepping until exit from function apic_timer_interrupt,
which has no line number information.
smp_apic_timer_interrupt (regs=0xffff810007437ed8) at
arch/x86/kernel/apic_64.c:488
488     {
(gdb) s
30              struct pt_regs *old_regs, **pp_regs =
&__get_cpu_var(__irq_regs);
(gdb) s
488     {
(gdb) s
30              struct pt_regs *old_regs, **pp_regs =
&__get_cpu_var(__irq_regs);
(gdb) s
450             struct clock_event_device *evt = &per_cpu(lapic_events,
cpu);
(gdb) s
32              old_regs = *pp_regs;
(gdb) s
33              *pp_regs = new_regs;
(gdb) s
64              *((volatile u32 *)(APIC_BASE + reg)) = v;
(gdb) c
Continuing.

<<-----------------------------------------GDB TEST

big thanks!

regards timo

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Mulyadi Santosa]

Hi

On Fri, May 9, 2008 at 4:03 PM, Keilhau Timo ( Student )
<timo.keilhau.student@thomson.net> wrote:
> Hello Jan, Jason and Mulyadi!
> BIG BIG thanks to you! It works now!
> You really have pointed me to the right solution.

Well, the credits certainly goes to Jason.... i remember his name
quite strong because once I also studied how the hell breakpoint
management is done in Qemu :D

regards,

Mulyadi.

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Daniel Jacobowitz]

On Thu, May 08, 2008 at 11:39:11PM -0500, Jason Wessel wrote:
> +@item maintenance packet qqemu.sstepbits

Are these packets in wide use yet?  If not, I'd really recommend you
use qRcmd instead; then the GDB command is just "monitor", e.g.
"monitor show sstepbits".  maint packet isn't really intended for
users.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Jason Wessel]

Daniel Jacobowitz wrote:
> On Thu, May 08, 2008 at 11:39:11PM -0500, Jason Wessel wrote:
>   
>> +@item maintenance packet qqemu.sstepbits
>>     
>
> Are these packets in wide use yet?  If not, I'd really recommend you
> use qRcmd instead; then the GDB command is just "monitor", e.g.
> "monitor show sstepbits".  maint packet isn't really intended for
> users.
>
>   
I highly doubt there is any kind of wide spread use here. This is qemu
specific and at that, it is really low level.

Because you mentioned it though I'll have a look. I seem to recall there
was some kind of encoding for monitor packets which should be straight
forward enough.

Thanks,
Jason.

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Daniel Jacobowitz]

On Fri, May 09, 2008 at 09:47:19AM -0500, Jason Wessel wrote:
> Because you mentioned it though I'll have a look. I seem to recall there
> was some kind of encoding for monitor packets which should be straight
> forward enough.

Right.  GDB just hex encodes everything after the word "monitor" and
passes it to the target.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Edgar E. Iglesias]

On Fri, May 09, 2008 at 10:40:29AM -0400, Daniel Jacobowitz wrote:
> On Thu, May 08, 2008 at 11:39:11PM -0500, Jason Wessel wrote:
> > +@item maintenance packet qqemu.sstepbits
> 
> Are these packets in wide use yet?  If not, I'd really recommend you
> use qRcmd instead; then the GDB command is just "monitor", e.g.
> "monitor show sstepbits".  maint packet isn't really intended for
> users.

Thanks for the comments Daniel.

This patch tries to change the syntax into this:
% monitor sstepbits
% monitor sstep
% monitor sstep=0x05

Or would a show/set interface be prefered for some reason (e.g, monitor show sstepbits, monitor show sstep, monitor set sstep 0x5)?

Best regards,
-- 
Edgar E. Iglesias
Axis Communications AB

Index: gdbstub.c
===================================================================
--- gdbstub.c	(revision 4432)
+++ gdbstub.c	(working copy)
@@ -1115,29 +1115,40 @@
     case 'q':
     case 'Q':
         /* parse any 'q' packets here */
-        if (!strcmp(p,"qemu.sstepbits")) {
-            /* Query Breakpoint bit definitions */
-            sprintf(buf,"ENABLE=%x,NOIRQ=%x,NOTIMER=%x",
-                    SSTEP_ENABLE,
-                    SSTEP_NOIRQ,
-                    SSTEP_NOTIMER);
-            put_packet(s, buf);
-            break;
-        } else if (strncmp(p,"qemu.sstep",10) == 0) {
-            /* Display or change the sstep_flags */
-            p += 10;
-            if (*p != '=') {
-                /* Display current setting */
-                sprintf(buf,"0x%x", sstep_flags);
-                put_packet(s, buf);
-                break;
-            }
-            p++;
-            type = strtoul(p, (char **)&p, 16);
-            sstep_flags = type;
-            put_packet(s, "OK");
-            break;
-        }
+	    if (!strncmp(p, "Rcmd,", 5)) {
+		    p += 5;
+		    len = strlen(p);
+		    hextomem(mem_buf, p, len);
+		    mem_buf[(len >> 1)] = 0;
+
+		    /* match hex for 'sstepbits'.  */
+		    if (!strcmp(mem_buf,"sstepbits")) {
+			    /* Query Breakpoint bit definitions */
+			    len = sprintf(mem_buf,
+					  "ENABLE=%x,NOIRQ=%x,NOTIMER=%x\n",
+					  SSTEP_ENABLE,
+					  SSTEP_NOIRQ,
+					  SSTEP_NOTIMER);
+			    memtohex(buf, mem_buf, len);
+			    put_packet(s, buf);
+			    break;			    
+		    } else if (!strncmp(mem_buf, "sstep", 5)) {
+			    /* Display or change the sstep_flags */
+			    if (mem_buf[5] != '=') {
+				    /* Display current setting */
+				    len = sprintf(mem_buf,"0x%x\n", sstep_flags);
+				    memtohex(buf, mem_buf, len);
+				    put_packet(s, buf);
+				    break;
+			    }
+			    p++;
+			    /* TODO: Add error checking.  */
+			    type = strtoul(mem_buf + 6, NULL, 16);
+			    sstep_flags = type;
+			    put_packet(s, "OK");
+			    break;
+		    }
+	    }
 #ifdef CONFIG_LINUX_USER
         else if (strncmp(p, "Offsets", 7) == 0) {
             TaskState *ts = env->opaque;
Index: qemu-doc.texi
===================================================================
--- qemu-doc.texi	(revision 4432)
+++ qemu-doc.texi	(working copy)
@@ -1952,29 +1952,25 @@
 
 The default single stepping behavior is step with the IRQs and timer service routines off.  It is set this way because when gdb executes a single step it expects to advance beyond the current instruction.  With the IRQs and and timer service routines on, a single step might jump into the one of the interrupt or exception vectors instead of executing the current instruction. This means you may hit the same breakpoint a number of times before executing the instruction gdb wants to have executed.  Because there are rare circumstances where you want to single step into an interrupt vector the behavior can be controlled from GDB.  There are three commands you can query and set the single step behavior:
 @table @code
-@item maintenance packet qqemu.sstepbits
+@item monitor sstepbits
 
 This will display the MASK bits used to control the single stepping IE:
 @example
-(gdb) maintenance packet qqemu.sstepbits
-sending: "qqemu.sstepbits"
-received: "ENABLE=1,NOIRQ=2,NOTIMER=4"
+(gdb) monitor sstepbits
+ENABLE=1,NOIRQ=2,NOTIMER=4
 @end example
-@item maintenance packet qqemu.sstep
+@item monitor sstep
 
 This will display the current value of the mask used when single stepping IE:
 @example
-(gdb) maintenance packet qqemu.sstep
-sending: "qqemu.sstep"
-received: "0x7"
+(gdb) monitor sstep
+0x7
 @end example
-@item maintenance packet Qqemu.sstep=HEX_VALUE
+@item monitor sstep=HEX_VALUE
 
 This will change the single step mask, so if wanted to enable IRQs on the single step, but not timers, you would use:
 @example
-(gdb) maintenance packet Qqemu.sstep=0x5
-sending: "qemu.sstep=0x5"
-received: "OK"
+(gdb) monitor sstep=0x5
 @end example
 @end table
 

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Jason Wessel]

Edgar E. Iglesias wrote:
> On Fri, May 09, 2008 at 10:40:29AM -0400, Daniel Jacobowitz wrote:
>   
>> On Thu, May 08, 2008 at 11:39:11PM -0500, Jason Wessel wrote:
>>     
>>> +@item maintenance packet qqemu.sstepbits
>>>       
>> Are these packets in wide use yet?  If not, I'd really recommend you
>> use qRcmd instead; then the GDB command is just "monitor", e.g.
>> "monitor show sstepbits".  maint packet isn't really intended for
>> users.
>>     
>
> Thanks for the comments Daniel.
>
> This patch tries to change the syntax into this:
> % monitor sstepbits
> % monitor sstep
> % monitor sstep=0x05
>
> Or would a show/set interface be prefered for some reason (e.g, monitor show sstepbits, monitor show sstep, monitor set sstep 0x5)?
>
> Best regards,
>   

The patch itself looks ok, but if you can hold off committing it, I'll
provide you with a two patch series in the next day or so which has even
more functionality.   I implemented gdb monitor commands as well as
"qemu pass through monitor" commands where you can using the gdb monitor
command to send commands and receive input from the qemu monitor as well.

Thanks,
Jason.

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Daniel Jacobowitz]

On Mon, May 12, 2008 at 11:41:03AM +0200, Edgar E. Iglesias wrote:
> Thanks for the comments Daniel.
> 
> This patch tries to change the syntax into this:
> % monitor sstepbits
> % monitor sstep
> % monitor sstep=0x05
> 
> Or would a show/set interface be prefered for some reason (e.g,
> monitor show sstepbits, monitor show sstep, monitor set sstep 0x5)?

The only reason I suggested set/show is that that's how the GDB
command line works.  I think the important part is using monitor
rather than custom packets; the set style is just sugar.

Thanks!

-- 
Daniel Jacobowitz
CodeSourcery

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Edgar E. Iglesias]

On Mon, May 12, 2008 at 07:51:00AM -0500, Jason Wessel wrote:
> Edgar E. Iglesias wrote:
> > On Fri, May 09, 2008 at 10:40:29AM -0400, Daniel Jacobowitz wrote:
> >   
> >> On Thu, May 08, 2008 at 11:39:11PM -0500, Jason Wessel wrote:
> >>     
> >>> +@item maintenance packet qqemu.sstepbits
> >>>       
> >> Are these packets in wide use yet?  If not, I'd really recommend you
> >> use qRcmd instead; then the GDB command is just "monitor", e.g.
> >> "monitor show sstepbits".  maint packet isn't really intended for
> >> users.
> >>     
> >
> > Thanks for the comments Daniel.
> >
> > This patch tries to change the syntax into this:
> > % monitor sstepbits
> > % monitor sstep
> > % monitor sstep=0x05
> >
> > Or would a show/set interface be prefered for some reason (e.g, monitor show sstepbits, monitor show sstep, monitor set sstep 0x5)?
> >
> > Best regards,
> >   
> 
> The patch itself looks ok, but if you can hold off committing it, I'll
> provide you with a two patch series in the next day or so which has even
> more functionality.   I implemented gdb monitor commands as well as
> "qemu pass through monitor" commands where you can using the gdb monitor
> command to send commands and receive input from the qemu monitor as well.

Great, let's wait for your patches.

Best regards
-- 
Edgar E. Iglesias
Axis Communications AB

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Edgar E. Iglesias]

On Mon, May 12, 2008 at 07:51:00AM -0500, Jason Wessel wrote:
> Edgar E. Iglesias wrote:
> > On Fri, May 09, 2008 at 10:40:29AM -0400, Daniel Jacobowitz wrote:
> >   
> >> On Thu, May 08, 2008 at 11:39:11PM -0500, Jason Wessel wrote:
> >>     
> >>> +@item maintenance packet qqemu.sstepbits
> >>>       
> >> Are these packets in wide use yet?  If not, I'd really recommend you
> >> use qRcmd instead; then the GDB command is just "monitor", e.g.
> >> "monitor show sstepbits".  maint packet isn't really intended for
> >> users.
> >>     
> >
> > Thanks for the comments Daniel.
> >
> > This patch tries to change the syntax into this:
> > % monitor sstepbits
> > % monitor sstep
> > % monitor sstep=0x05
> >
> > Or would a show/set interface be prefered for some reason (e.g, monitor show sstepbits, monitor show sstep, monitor set sstep 0x5)?
> >
> > Best regards,
> >   
> 
> The patch itself looks ok, but if you can hold off committing it, I'll
> provide you with a two patch series in the next day or so which has even
> more functionality.   I implemented gdb monitor commands as well as
> "qemu pass through monitor" commands where you can using the gdb monitor
> command to send commands and receive input from the qemu monitor as well.

Btw, while your at it you might want to consider another comment. When trying the sstep I felt it was easy to get confused with the negated bitmasks. Maybe we should invert them?

The default bitmask would change to 1. And sstepbits would be "ENABLE=1,IRQ=2,TIMERS=4". Does that make sense?

Best regards
-- 
Edgar E. Iglesias
Axis Communications AB

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Jason Wessel]

Edgar E. Iglesias wrote:
> On Mon, May 12, 2008 at 07:51:00AM -0500, Jason Wessel wrote:
>   
>> Edgar E. Iglesias wrote:
>>     
>>> On Fri, May 09, 2008 at 10:40:29AM -0400, Daniel Jacobowitz wrote:
>>>   
>>>       
>>>> On Thu, May 08, 2008 at 11:39:11PM -0500, Jason Wessel wrote:
>>>>     
>>>>         
>>>>> +@item maintenance packet qqemu.sstepbits
>>>>>       
>>>>>           
>>>> Are these packets in wide use yet?  If not, I'd really recommend you
>>>> use qRcmd instead; then the GDB command is just "monitor", e.g.
>>>> "monitor show sstepbits".  maint packet isn't really intended for
>>>> users.
>>>>     
>>>>         
>>> Thanks for the comments Daniel.
>>>
>>> This patch tries to change the syntax into this:
>>> % monitor sstepbits
>>> % monitor sstep
>>> % monitor sstep=0x05
>>>
>>> Or would a show/set interface be prefered for some reason (e.g, monitor show sstepbits, monitor show sstep, monitor set sstep 0x5)?
>>>
>>> Best regards,
>>>   
>>>       
>> The patch itself looks ok, but if you can hold off committing it, I'll
>> provide you with a two patch series in the next day or so which has even
>> more functionality.   I implemented gdb monitor commands as well as
>> "qemu pass through monitor" commands where you can using the gdb monitor
>> command to send commands and receive input from the qemu monitor as well.
>>     
>
> Btw, while your at it you might want to consider another comment. When trying the sstep I felt it was easy to get confused with the negated bitmasks. Maybe we should invert them?
>
> The default bitmask would change to 1. And sstepbits would be "ENABLE=1,IRQ=2,TIMERS=4". Does that make sense?
>
>   

I don't care one way or the other about the negated bit mask. I'll as
the question of which is the least expensive condition to check.

if ( it_is_irq && !(env->singlestep_enabled & SSTEP_NOIRQ))
do_irq

Or

if ( it_is_irq && !(env->singlestep_enabled && (env->singlestep_enabled
& SSTEP_IRQ)))
do_irq


Perhaps the compiler makes enough of an optimization in the later that
we need not worry? In the case of the code the way it was now, it was
clearly "visually optimized". ;-)

Jason.

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Paul Brook]

> Btw, while your at it you might want to consider another comment. When
> trying the sstep I felt it was easy to get confused with the negated
> bitmasks. Maybe we should invert them?
>
> The default bitmask would change to 1. And sstepbits would be
> "ENABLE=1,IRQ=2,TIMERS=4". Does that make sense?

Or just have the command use symbolic names rather than numeric values.

Paul

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Edgar E. Iglesias]

On Mon, May 12, 2008 at 03:33:31PM +0100, Paul Brook wrote:
> > Btw, while your at it you might want to consider another comment. When
> > trying the sstep I felt it was easy to get confused with the negated
> > bitmasks. Maybe we should invert them?
> >
> > The default bitmask would change to 1. And sstepbits would be
> > "ENABLE=1,IRQ=2,TIMERS=4". Does that make sense?
> 
> Or just have the command use symbolic names rather than numeric values.

Even better :)
Jason, I was refering to the user exposed interface. Internally you can handle it the way you want.

-- 
Edgar E. Iglesias
Axis Communications AB

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..

[Jason Wessel]

Paul Brook wrote:
>> Btw, while your at it you might want to consider another comment. When
>> trying the sstep I felt it was easy to get confused with the negated
>> bitmasks. Maybe we should invert them?
>>
>> The default bitmask would change to 1. And sstepbits would be
>> "ENABLE=1,IRQ=2,TIMERS=4". Does that make sense?
>>     
>
> Or just have the command use symbolic names rather than numeric values.
>
> Paul
>   
In terms of the user interface, it looks like:

(gdb) monitor help
gdbstub specific monitor commands:
s_show -- Show gdbstub Single Stepping variables
set s_step <0|1> -- Single Stepping enabled
set s_irq <0|1> -- Single Stepping with qemu irq handlers enabled
set s_timer <0|1> -- Single Stepping with qemu timers enabled
qemu monitor pass-through commands:
help|? [cmd] -- show the help
commit device|all -- commit changes to the disk images (if -snapshot is
used) or backing files
info subcommand -- show various information about the system state
q|quit -- quit the emulator
[...clip... normal qemu monitor stuff]

(gdb) monitor s_show
s_step == 1
s_irq == 0
s_timer == 0

The implementation of the internals with the #defines did not change in
any fundamental way. The patches for this will be posted after further
testing in the next day or so for further comments. Also the timers
option is probably going to go away entirely.

Jason.