Re: [PATCH] RS6000 and PowerPC CPU types

[Geoff Keating <geoffk at cygnus dot com>]

> Date: Fri, 12 May 2000 18:20:48 -0400
> From: Nick Duffek <nsd@cygnus.com>
> CC: binutils@sourceware.cygnus.com
> 
> On 12-May-2000, Geoff Keating wrote:
> 
> >> This is not strictly correct, because (a) there are 64-bit CPUs other than
> >> the 620 (e.g. the 630) and (b) the 620 can run non-XCOFF64 binaries.
> 
> >This is certainly true.  (b) is true for all 64-bit CPUs.  I don't see
> >why it makes a difference.
> 
> AIX GDB displays different registers sets for different CPUs.

Good.  I don't see your point.

> >This seems wrong.  It should determine the CPU being debugged by
> >looking at the hardware, not looking at the object file.
> 
> I disagree.  Even if a binary is only usable on CPU type A, GDB on CPU
> type B should still be able to examine that binary plus a core file
> generated by CPU type A, displaying registers appropriate for CPU type A.

Yes.  In this case, the 'hardware' is whatever generated the core
file.  Similarly if GDB is running on one place but debugging a binary
somewhere else (via gdbserver, for instance).  In any case, core files
are not in XCOFF format, and I think you want to be reading the c_impl
field of the core_dumpx structure stored in the core file.

It is probably useful that if the user takes a binary which only runs
on CPU type A, tries to run it on CPU type B, and runs gdb on the
resulting core file, then gdb should not crash trying to read
nonexistent registers :-).

> >It is
> >meaningless to try to match a CPU model with an object file,
> 
> If the o_cputype field is set to something other than 0, then isn't it
> likely that the object file is somehow specific to that CPU?

Not really.  I think MacOS sets it to 603 by default, for instance.
In fact, if it is set to 0, that means 'old POWER'.  5, TCPU_ANY,
means a mixture; 3, TCPU_COM, means the common subset of POWER and
PowerPC.  There doesn't seem to be a setting for 'uses 64-bit
instructions but not running in 64-bit mode'.

> >consider
> >for instance an object file that contains code for bit-blitting and
> >has six routines with identical behaviour but using different CPU
> >features (like altivec and 64-bit instructions).
> 
> In that case, the o_cputype field should be 0, in which case GDB would
> choose the lowest common denominator.

It would depend on what it is choosing it for.  If it is doing
disassembly, it needs to know about all the instructions, so that if
the user gets a SIGILL the user knows which instruction he shouldn't
be using.  If it is displaying registers, it wants to display the
registers that actually exist.

-- 
- Geoffrey Keating <geoffk@cygnus.com>