This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Towards better x86 system debugging support


Samuel Bronson wrote:
> 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?

Unfortunately not. I was hoping my todo list would shrink a bit or some
customer explicitly ask for a clean integration, but both did not happen
yet. But it's not forgotten, it's just "slightly" delayed.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]