From: Doug Evans <dje@google.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: gdb@sourceware.org, Daniel Jacobowitz <drow@false.org>
Subject: Re: Towards better x86 system debugging support
Date: Tue, 06 Jan 2009 23:59:00 -0000 [thread overview]
Message-ID: <e394668d0901061559v6e866b25g6107bd79babc4949@mail.gmail.com> (raw)
In-Reply-To: <4960BAC8.7020801@web.de>
On Sun, Jan 4, 2009 at 5:34 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
> Hi,
>
> as many of you may know, there is a gdb server in QEMU that allows to
> debug kernels, boot loaders and other low-level stuff without real
> target hardware. I'm e.g. using it heavily for analyzing Linux kernel
> issues on x86 targets (thanks to KVM, you can even debug weird SMP races
> in NMI-using kernel debuggers...).
>
> Unfortunately, the x86 support is incomplete in so far that neither the
> gdb remote protocol nor the gdb backend are aware of most special
> registers x86 system-level software uses. This comes with several drawbacks:
>
> o Current code bit width (16, 32 or 64) is unknown to the debugger,
> so correct disassembling is not automatically possible
> o Real mode cannot be detected, which would include setting 16 bit
> disassembly mode and calculating segment bases appropriately
> o Manually setting the architecture (set arch i8086/i386/i386:x86-64)
> influences the register set layout of the remote protocol, preventing
> straightforward switches from 16-bit bootloader/BIOS code to 64-bit
> kernel code (to give just one example)
> o Only flat memory models are supported and debugging becomes very
> hairy when some segment uses a non-zero base address - note that this
> also prevents support for TLS variable lookup (which is GS or
> FS-based)
>
> As a first step toward enhanced x86 support, I think there is a need for
> an extended register set in the remote protocol. The following registers
> should be added:
>
> o GDTR, LDTR, IDTR, TR (visible part, ie. selector value)
> o CR0..4
> o DR0..7
> o selected MSRs, at least
> - IA32_EFER (64-bit mode detection)
> - IA32_FS_Base (TLS)
> - IA32_GS_Base (TLS)
> - IA32_KernelGSbase (TLS)
> o Shadow states of segment registers, GDTR, LDTR, IDTR and TR
> (relevant for virtual targets where the VM often has access to these
> hidden states, helpful when debugging targets that modify in-use
> descriptor table entries)
>
> If anyone thinks that there should be more registers or MSRs included,
> please extend this list!
I know of one linux program that uses modify_ldt() and changes all
segment registers, so I would add cs_base,ds_base,es_base,ss_base.
Some folks would presumably find *_limit, *_flags useful too.
prev parent reply other threads:[~2009-01-06 23:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-04 13:34 Jan Kiszka
2009-01-05 3:44 ` Daniel Jacobowitz
2009-01-05 8:52 ` GDB MI and actual type of a pointer or reference Elmenthaler, Jens
2009-01-05 9:36 ` Towards better x86 system debugging support Jan Kiszka
2009-01-06 15:14 ` Daniel Jacobowitz
2009-01-05 20:20 ` Mark Kettenis
2009-01-06 12:13 ` Jan Kiszka
2009-05-29 19:20 ` Samuel Bronson
2009-05-31 9:36 ` Jan Kiszka
2009-01-06 23:59 ` Doug Evans [this message]
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=e394668d0901061559v6e866b25g6107bd79babc4949@mail.gmail.com \
--to=dje@google.com \
--cc=drow@false.org \
--cc=gdb@sourceware.org \
--cc=jan.kiszka@web.de \
/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