From: Pierre-Alexandre Meyer <pierre@mouraf.org>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Dump registers?
Date: Sun, 22 Feb 2009 20:54:12 +0100 [thread overview]
Message-ID: <20090222195411.GO28647@panda> (raw)
Good morning,
I am developing an application at the bootloader level that
eventually jumps into protected mode. My testing is done using the
qemu Ubuntu Intrepid build (0.9.1).
Doing something like
qemu -M pc -hda foo.vmdk -m 1000 -no-kqemu -boot c -S -s
and connecting gdb works great... until the application jumps into
protected mode when gdb becomes really confused.
Setting a break point at the first function after protected mode doesn't
work.
With no break points, if I SIGINT the program after the jump, gdb is confused:
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
This makes sense I suppose since the segment registers were changed
since gdb was started. I have then access to the registers but I am not sure
how accurate they are.
Is there a way to ask qemu to dump these registers (as well as the
descriptor tables)? I saw once a dump like:
qemu: fatal: triple fault
EAX=6000004d EBX=00000914 ECX=00000000 EDX=000028a3
ESI=00000000 EDI=00005443 EBP=00000028 ESP=00007c48
EIP=00002800 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 008f9300
CS =0008 00000000 0000ffff 00009b00
SS =0038 00000000 0000ffff 00009300
DS =0010 00000000 ffffffff 008f9300
FS =0018 00000000 0000ffff 00009300
GS =0018 00000000 0000ffff 00009300
LDT=0000 00000000 00000000 00008000
TR =0030 0000285c 00000067 00008900
GDT= 000028c4 0000003f
IDT= 00000000 0000ffff
CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000
CCS=6000004d CCD=600000d0 CCO=ADDB
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000
XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000
XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000
XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000
XMM07=00000000000000000000000000000000
This is exactly what I am looking for. Any idea if I can force such a
dump on demand and/or fix gdb?
Thank you.
(Please CC: me when replying, since I am not on the list)
--
Pierre-Alexandre Meyer
next reply other threads:[~2009-02-22 19:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-22 19:54 Pierre-Alexandre Meyer [this message]
2009-02-23 6:46 ` [Qemu-devel] Dump registers? malc
2009-02-24 4:16 ` Pierre-Alexandre Meyer
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=20090222195411.GO28647@panda \
--to=pierre@mouraf.org \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.