From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12020 invoked by alias); 29 Aug 2002 23:44:33 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12008 invoked from network); 29 Aug 2002 23:44:33 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 29 Aug 2002 23:44:33 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17kZu1-0006sx-00; Thu, 29 Aug 2002 19:44:46 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17kYyu-0007yV-00; Thu, 29 Aug 2002 19:45:44 -0400 Date: Thu, 29 Aug 2002 17:30:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] Query Red Boot's i386 CPU id Message-ID: <20020829234544.GB29966@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3D6D4142.2070007@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6D4142.2070007@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg01021.txt.bz2 On Wed, Aug 28, 2002 at 05:31:46PM -0400, Andrew Cagney wrote: > Comments on how this was implemented, and what, if anything, could be > integrated into GDB, welcome. > +/* NOTE: cagney/2001-11-17: > + > + This module uses the [remote protocol] target_query ("qCPUID") > + method to extract the i386 CPU information. It then takes that > + information and uses it to do a lookup on a local file > + ``cpuid-i386''. > + > + Thanks to a botched initial thread query mechanism, using anything > + starting with ``qC'' is dangerous. Since qCPUID does this, it > + won't interact well with targets that recognize the exiting ``qC'' > + query. Sigh. > + > + One possible alternative to this qCPUID mechanis would be to plant > + a CPUID instruction in the target memory, execute it, and then > + examine the result. This probably isn't pratical since it depends > + in being able to execute code in the target. > + > + This file adds the command ``info cpu''. Beware of the existing > + commands ``{set,show} {processor,architecture}''. > + > + This file uses a target_post_open_hook() mechanism to hook into the > + target open (and report the CPUID on an initial connect). Per the > + comment in the file "target.h", what really should be happening is > + a core_gdb_open() function should be calling the hook. */ That comment is pretty thorough about my concerns :) Gdbserver doesn't support qC yet (just realized a moment ago that it probably should). But qCPUID really doesn't work with that. I bet there's deployed RedBoot stubs that have this problem? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer