This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: [PATCH] RS6000 and PowerPC CPU types
- To: nsd at cygnus dot com
- Subject: Re: [PATCH] RS6000 and PowerPC CPU types
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Fri, 12 May 2000 14:44:57 -0700
- CC: binutils at sourceware dot cygnus dot com
- References: <200005121947.TAA08250@nog.bosbc.com>
> 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>