From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17579 invoked by alias); 5 Jan 2009 09:36:23 -0000 Received: (qmail 17566 invoked by uid 22791); 5 Jan 2009 09:36:22 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from fmmailgate01.web.de (HELO fmmailgate01.web.de) (217.72.192.221) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Jan 2009 09:36:17 +0000 Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate01.web.de (Postfix) with ESMTP id B7919FB65A44; Mon, 5 Jan 2009 10:36:13 +0100 (CET) Received: from [88.64.5.158] (helo=[192.168.1.198]) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #273) id 1LJlsb-0001jH-00; Mon, 05 Jan 2009 10:36:13 +0100 Message-ID: <4961D487.1030707@web.de> Date: Mon, 05 Jan 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: Daniel Jacobowitz CC: gdb@sourceware.org Subject: Re: Towards better x86 system debugging support References: <4960BAC8.7020801@web.de> <20090105034419.GA20581@caradoc.them.org> In-Reply-To: <20090105034419.GA20581@caradoc.them.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB7212F40E7B9D21192E7C6E5" 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-01/txt/msg00011.txt.bz2 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7212F40E7B9D21192E7C6E5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 1212 Daniel Jacobowitz wrote: > On Sun, Jan 04, 2009 at 02:34:00PM +0100, Jan Kiszka wrote: >> The question for me is how to extend the protocol precisely. I guess we >> need some new qSupported feature. But should we then, if both sides >> agreed on it, switch to a completely new register set or rather exchange >> those additional registers separately, ie. via some new packet? >=20 > No new feature required. Take a look at the description of > target-described registers in the current manual; we'd just need > a naming convention for the x86 control registers of interest to GDB. > That solves your other issue too about width. Ah, of course, once again forgot about this. So another convention would be that a target capable of up to 32 bit mode would report its registers as 32 bit and a 64 bit target as 64 bit - and they would transfer this width _independent_ of the current mode. That leads me to the questions: o Roughly, what code changes are required to exchange some i386.xml or x86-64.xml? o If gdb accepted such a static XML description from some x86 target, would it already stick with the register layout even when setting the arch manually (or later automatically)? Thanks, Jan --------------enigB7212F40E7B9D21192E7C6E5 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 iEYEARECAAYFAklh1IwACgkQniDOoMHTA+nz3wCeN2wJSHszIOsjIyAUl1BKhhtO S5gAn0+PtSiCD9YQ8IH4ewtvDWtcIk1C =2yik -----END PGP SIGNATURE----- --------------enigB7212F40E7B9D21192E7C6E5--