From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32059 invoked by alias); 31 May 2009 09:36:57 -0000 Received: (qmail 32045 invoked by uid 22791); 31 May 2009 09:36:55 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_23 X-Spam-Check-By: sourceware.org Received: from fmmailgate03.web.de (HELO fmmailgate03.web.de) (217.72.192.234) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 31 May 2009 09:36:50 +0000 Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate03.web.de (Postfix) with ESMTP id 485FEFE7D534; Sun, 31 May 2009 11:36:48 +0200 (CEST) Received: from [92.74.63.249] (helo=[192.168.1.3]) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1MAhTE-0003NF-00; Sun, 31 May 2009 11:36:48 +0200 Message-ID: <4A224FA6.7050501@web.de> Date: Sun, 31 May 2009 09:36:00 -0000 From: Jan Kiszka User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Samuel Bronson CC: gdb@sources.redhat.com Subject: Re: Towards better x86 system debugging support References: <4960BAC8.7020801@web.de> <200901052020.n05KKg3d014109@brahms.sibelius.xs4all.nl> <49634AE3.4020400@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3A4353269FE75A61CD7ACF0E" X-Sender: jan.kiszka@web.de 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/msg00211.txt.bz2 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3A4353269FE75A61CD7ACF0E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 2428 Samuel Bronson wrote: > Jan Kiszka web.de> writes: >> Mark Kettenis wrote: >>>> From: Jan Kiszka web.de> >=20 >>>> 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 draw= backs: >=20 >>>> o Current code bit width (16, 32 or 64) is unknown to the debugger, >>>> so correct disassembling is not automatically possible >=20 >>>> o Real mode cannot be detected, which would include setting 16 bit >>>> disassembly mode and calculating segment bases appropriately >=20 >>>> o Only flat memory models are supported and debugging becomes very >>>> hairy when some segment uses a non-zero base address - note that th= is >>>> also prevents support for TLS variable lookup (which is GS or >>>> FS-based) >=20 >>>> As a first step toward enhanced x86 support, I think there is a need f= or >>>> an extended register set in the remote protocol. The following registe= rs >>>> should be added: >=20 >>>> 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) >=20 > These things have also been bothering me lately, along with GDB's poor ha= ndling > of interrupt handlers, namely: >=20 > o the "finish" command doesn't work in an interrupt-handler frame >=20 > o GDB (presumably) does not notice when a frame's (interrupt) return CS:E= IP > 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:ES= P, > which are stored on the stack in this situation rather than inferred > based on the present frame >=20 > 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 --------------enig3A4353269FE75A61CD7ACF0E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 257 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkoiT68ACgkQniDOoMHTA+nixQCfcUZdUcYE+Dh9FuKBxEr8ZxTA FIIAmgIGFCfF8Iar2zjiX0E36SzHGDd8 =l8fG -----END PGP SIGNATURE----- --------------enig3A4353269FE75A61CD7ACF0E--