From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15133 invoked by alias); 29 May 2009 19:20:16 -0000 Received: (qmail 15121 invoked by uid 22791); 29 May 2009 19:20:15 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_00,J_CHICKENPOX_23,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 29 May 2009 19:20:06 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1MA7cY-0000Rq-Rv for gdb@sources.redhat.com; Fri, 29 May 2009 19:20:03 +0000 Received: from 207-172-203-39.c3-0.upd-ubr7.trpr-upd.pa.cable.rcn.com ([207.172.203.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 May 2009 19:20:02 +0000 Received: from naesten by 207-172-203-39.c3-0.upd-ubr7.trpr-upd.pa.cable.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 May 2009 19:20:02 +0000 To: gdb@sources.redhat.com From: Samuel Bronson Subject: Re: Towards better x86 system debugging support Date: Fri, 29 May 2009 19:20:00 -0000 Message-ID: References: <4960BAC8.7020801@web.de> <200901052020.n05KKg3d014109@brahms.sibelius.xs4all.nl> <49634AE3.4020400@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00191.txt.bz2 Jan Kiszka web.de> writes: > Mark Kettenis wrote: > >> From: Jan Kiszka 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?