This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Towards better x86 system debugging support
- From: Samuel Bronson <naesten at gmail dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 29 May 2009 19:16:36 +0000 (UTC)
- Subject: Re: Towards better x86 system debugging support
- References: <4960BAC8.7020801@web.de> <200901052020.n05KKg3d014109@brahms.sibelius.xs4all.nl> <49634AE3.4020400@web.de>
Jan Kiszka <jan.kiszka <at> web.de> writes:
> Mark Kettenis wrote:
> >> From: Jan Kiszka <jan.kiszka <at> web.de>
> >> 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 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)
These things have also been bothering me lately, along with GDB's poor handling
of interrupt handlers, namely:
o the "finish" command doesn't work in an interrupt-handler frame
o GDB (presumably) does not notice when a frame's (interrupt) return CS:EIP
is at a different privilege level from that frame's own CS:EIP, which it
would need to do in order to correctly unwind the calling frame's SS:ESP,
which are stored on the stack in this situation rather than inferred
based on the present frame
Have you made any progress on any of this, Jan?