qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, n


From: Jason Wessel
Subject: Re: [Qemu-devel] Debugging vmlinux with qemu and gdb. Unable to step, next, print or to get any information..
Date: Mon, 12 May 2008 09:31:28 -0500
User-agent: Thunderbird 2.0.0.14 (X11/20080502)

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:
>>>>     
>>>>         
>>>>> address@hidden 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]