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] |
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] |