Re: [rfc] Query Red Boot's i386 CPU id

[Andrew Cagney <ac131313@ges.redhat.com>]

> 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