This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] RS6000 and PowerPC CPU types


> 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>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]