[PATCH] RS6000 and PowerPC CPU types

[Geoff Keating]

> Mailing-List: contact binutils-help@sourceware.cygnus.com; run by ezmlm
> List-Unsubscribe: < mailto:binutils-unsubscribe-geoffk=cygnus.com@sourceware.cygnus.com >
> List-Subscribe: < mailto:binutils-subscribe@sourceware.cygnus.com >
> List-Archive: < http://sourceware.cygnus.com/ml/binutils/ >
> List-Post: < mailto:binutils@sourceware.cygnus.com >
> List-Help: < mailto:binutils-help@sourceware.cygnus.com >, < http://sourceware.cygnus.com/ml/#faqs >
> Date: Fri, 12 May 2000 19:47:13 GMT
> From: "Nick Duffek <Nick Duffek"<nsd@cygnus.com>
> 
> The RS6000COFF_C section of coff_set_arch_mach_hook() attempts to infer
> the architecture and machine from the o_cputype field of the a.out header.
> 
> On AIX, o_cputype is usually 0, meaning that the CPU can be anything.
> coff_set_arch_mach_hook() interprets that to mean the following:
>   - if the binary format is XCOFF64, the CPU is a 620
>   - otherwise, the CPU is a 6000
> 
> 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 cares somewhat about the particular CPU being debugged, so I made
> an attempt to correct the above.  I also added checks for all CPU types
> documented in /usr/include/aouthdr.h and removed the corresponding "We
> don't handle all cases here" FIXME.

This seems wrong.  It should determine the CPU being debugged by
looking at the hardware, not looking at the object file.
coff_set_arch_mach_hook can't do this because hardware may not be
available, but GDB doesn't have this problem.

In practise, none of this should really make a difference.  It is
meaningless to try to match a CPU model with an object file, 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).  All the tools should
behave sanely on such a file.

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