From: prime <guomingyan@gmail.com>
To: Tace <tacetan@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Make QEMU more friendly for kernel debug
Date: Sun, 26 Feb 2006 14:18:42 +0800 [thread overview]
Message-ID: <1fa17f810602252218v29909709ue2211616ad044719@mail.gmail.com> (raw)
In-Reply-To: <92c265230602252042r5adf23a0y7de4d2c4905110c8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]
On 2/26/06, Tace <tacetan@gmail.com> wrote:
>
> Hi,
> Please do...
>
> I got a question, doesn't disable the interrupts changes the
> underlying system? Perhaps a good way would be to monitor the
> completion of the interrupt routine before singlestepping to the next
> instruction?
>
>
> On 2/23/06, prime <guomingyan@gmail.com> wrote:
> > Hello everyone,
> > I find that I can't single step OS kernels use qemu.When I use
> "step"
> > or "next" command in gdb,the kernel always enter its interrupt route
> > instead of executing the next instruction after the breakpoint.So I
> modify
> > QEMU's source code to disable interrupts in single step mode,and now I
> > can use "step" or "next" command in gdb to single step functions.
> >
> > Should I post the patch? It is a very small modification.
> >
> > --
> > Three passions, simple but overwhelmingly strong, have governed my life:
> > the longing for love, the search for knowledge, and unbearable pity for
> > the suffering of mankind.
> > ---------Bertrand Russell
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
> >
> >
>
Hi,
I have post the patch here http://qemu.dad-answers.com/viewtopic.php?t=921
Disable interrupts in single step has very few
effects on the underlying system,in my opinion.
In normal mode(without single step),many
instructions are executed between two interrupts,
but in single step mode,we have done too much extra
ministrant work besides execute one instruction while the "virtual clock"
running. So only one
instruction can be executed between two clock
interrupts.And I think,disable interrupts in single
step mode is a simple method to cancel the "virtual time" we have used for
doing extra ministrant work.
For example,if we define CONFIG_SLIRP,then after
gdb_handle_packet() starts "virtual clock" by
vm_start(),we have to do much work to handle slirp,
and it needs lots "virtual time".This is just a
simple instance,and there are many cases elsewhere.
PS. Please forgive my poor English,and it is my second language.
--
Three passions, simple but overwhelmingly strong, have governed my life:
the longing for love, the search for knowledge, and unbearable pity for
the suffering of mankind.
---------Bertrand Russell
[-- Attachment #2: Type: text/html, Size: 3605 bytes --]
next prev parent reply other threads:[~2006-02-26 6:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-23 6:04 [Qemu-devel] Make QEMU more friendly for kernel debug prime
[not found] ` <92c265230602252042r5adf23a0y7de4d2c4905110c8@mail.gmail.com>
2006-02-26 6:18 ` prime [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-02-24 7:46 prime
2006-02-25 8:13 ` Mulyadi Santosa
2006-02-25 10:56 ` prime
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1fa17f810602252218v29909709ue2211616ad044719@mail.gmail.com \
--to=guomingyan@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=tacetan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).