From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21197 invoked by alias); 30 Aug 2002 19:57: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 21159 invoked from network); 30 Aug 2002 19:57:32 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 30 Aug 2002 19:57:32 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 542A83C67; Fri, 30 Aug 2002 15:57:32 -0400 (EDT) Message-ID: <3D6FCE2C.6050607@ges.redhat.com> Date: Fri, 30 Aug 2002 13:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] Query Red Boot's i386 CPU id References: <3D6D4142.2070007@ges.redhat.com> <20020829234544.GB29966@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg01047.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? The comment comes from looking at old stub code: if (b[0] == 'q' && b[1] == 'C') handle_crc (); It really depends on how [badly] the stub is written. RedBoot stubs (from memory) check qCPUID first --- actually they must as the patch works with RedBoot. Andrew