I generated a gcc crosscompiler for PPC 7400 using a sparc Solaris 2.8 system 
as the host. For the record, in order to compile the all tool chain I used Dan 
kegel "crosstool" script (crosstool-0.28-rc25). This script applies some 
patches to GCC 3.4.0. in particular it applies a patch to 
gcc/config/rs6000/rs6000.h where it adds (amon other things) an unconditional 
-many option to be passed to the assembler. By browsing the GCC CVS it appears 
that this patch is now part of mainline. 
 
I selected the following components to build my crosstool chain: 
GCC 3.4.O 
BINUTILS 2.14 
GLIBC 2.3.2 
 
My crosstool chain was configured with the following "configure" command: 
 
/export/home/jdubois/crosstool-0.28-rc25/build/powerpc-7400-linux-gnu/gcc-3.4.0-glibc-2.3.2/gcc-3.4.0/configure 
--target=powerpc-7400-linux-gnu --host=sparc-host_sun-solaris2.8 
--prefix=/vobs/target_tools/sparc-unknown-solaris-gnu/powerpc-7400-linux-gnu/gcc-3.4.0-glibc-2.3.2 
--with-cpu=7400 --enable-altivec 
--with-headers=/vobs/target_tools/sparc-unknown-solaris-gnu/powerpc-7400-linux-gnu/gcc-3.4.0-glibc-2.3.2/powerpc-7400-linux-gnu/include 
--with-local-prefix=/vobs/target_tools/sparc-unknown-solaris-gnu/powerpc-7400-linux-gnu/gcc-3.4.0-glibc-2.3.2/powerpc-7400-linux-gnu 
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit 
--enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long 
Thread model: posix 
gcc version 3.4.0 
 
When compiling the Linux kernel (2.6.2) with this crosstool chain from Solaris 
for PPC 7400 target, the compilation will fail on arch/ppc/kernel/time.c. This 
is because the get_tbl() and get_tbu() functions (defined in 
include/asm-ppc/time.h) are PPC specific. They are defiend as follow: 
 
extern __inline__ unsigned long get_tbl(void) { 
        unsigned long tbl; 
#if defined(CONFIG_403GCX) 
        asm volatile("mfspr %0, 0x3dd" : "=r" (tbl)); 
#else 
        asm volatile("mftb %0" : "=r" (tbl)); 
#endif 
        return tbl; 
} 
 
extern __inline__ unsigned long get_tbu(void) { 
        unsigned long tbl; 
#if defined(CONFIG_403GCX) 
        asm volatile("mfspr %0, 0x3dc" : "=r" (tbl)); 
#else 
        asm volatile("mftbu %0" : "=r" (tbl)); 
#endif 
        return tbl; 
} 
 
These function are "translated" in the .i file as follow: 
 
extern __inline__ __attribute__((always_inline)) unsigned long get_tbl(void) { 
 unsigned long tbl; 
 
 asm volatile("mftb %0" : "=r" (tbl)); 
 
 return tbl; 
} 
 
extern __inline__ __attribute__((always_inline)) unsigned long get_tbu(void) { 
 unsigned long tbl; 
 
 asm volatile("mftbu %0" : "=r" (tbl)); 
 
 return tbl; 
} 
 
And then the .s file generated from this will contain some fragments looking as 
follow: 
 
#APP 
        mftb 0 
#NO_APP 
 
.... 
 
#APP 
        mftbu 0 
        mftb 6 
        mftbu 11 
#NO_APP 
 
So it looks like the "mftbX" opcode are not valid on PPC403. When compiling the 
Linux kernel for PPC7400, the "mftbX" version of the functions are selected and 
the resulting assembly code (generated by cc1) is passed to the assembler with 
the following options: "-mppc -maltivec -many". The 2 first options are OK but 
the last one seems to prevent the assembler to interpret the "mftbX" opcode and 
the assembler will fail with some messages similar to this: 
 
time.s: Assembler messages: 
time.s:158: Error: Unrecognized opcode: `mftb' 
time.s:376: Error: Unrecognized opcode: `mftb' 
time.s:500: Error: Unrecognized opcode: `mftb' 
time.s:685: Error: Unrecognized opcode: `mftb' 
time.s:802: Error: Unrecognized opcode: `mftb' 
time.s:1016: Error: Unrecognized opcode: `mftbu' 
time.s:1017: Error: Unrecognized opcode: `mftb' 
time.s:1018: Error: Unrecognized opcode: `mftbu' 
 
I regenerated the GCC 3.4.0 tool chain without the -many and the compiler was 
then able to compile the time.c file. 
 
So while the official GCC 3.4 tool chain should not contain this "fix" it seems 
to be quite an official one anyway as it is now part of mainline (3.5?). 
However it seems to me it causes some trouble in the Linux kernel compilation 
for PPC when the C code select itself the assembly code to use for a function. 
 
Therefore, I'd like to ask if this unconditional "-many" is really required. If 
it is, is there some kind of incompatibilty/misbehavior in the 2.14 binutils I 
selscted for the task? 
 
I don't see a way to attach the .c, .i or .s to this web form. So please let me 
know where/how to send it and I'll do it.