Shorter report: powerpc64-xtoolchain-gcc use fails from powerpc (non-64)

Mark Millard markmi at dsl-only.net
Wed Apr 1 21:44:50 UTC 2015


Attempting to use CROSS_TOOLCHAIN=powerpc64-gcc on powerpc (non-64) 11.0-CURRENT with TARGET_ARCH=powerpc64 gets:

> --- crti.o ---
> gcc -O2 -pipe   -I/usr/srcC/lib/csu/powerpc64/../common  -I/usr/srcC/lib/csu/powerpc64/../../libc/include  -mlongcall -std=gnu99  -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign    -c /usr/srcC/lib/csu/powerpc64/crti.S
> ...
> /usr/srcC/lib/csu/powerpc64/crti.S: Assembler messages:
> /usr/srcC/lib/csu/powerpc64/crti.S:35: Error: junk at end of line, first unrecognized character is `@'
> /usr/srcC/lib/csu/powerpc64/crti.S:51: Error: junk at end of line, first unrecognized character is `@'
> *** [crti.o] Error code 1
> 



Read below only for analysis.



First I'll deal with the error messages. Then I'll deal with the "gcc".

The lines of crti.S in question are:

>       .quad   .L._init,.TOC. at tocbase,0
> ...
>       .quad   .L._fini,.TOC. at tocbase,0

The error messages are because __powerpc64__ is not defined when machine/asm.h is included so the wrong definition is used for _ENTRY(...):

> #ifdef __powerpc64__
> ...
> #define _ENTRY(name) \
>        .section ".text"; \
>        .p2align 2; \
>        .globl  name; \
>        .section ".opd","aw"; \
>        .p2align 3; \
>        name: \
>        .quad   DOT_LABEL(name),.TOC. at tocbase,0; \
>        .previous; \
>        .p2align 4; \
>        TYPE_ENTRY(name) \
> DOT_LABEL(name):
> ...
> #else /* !__powerpc64__ */
> #define _ENTRY(name) \
>        .text; \
>        .p2align 4; \
>        .globl  name; \
>        .type   name, at function; \
>        name:
> #define _END(name)
> #endif /* __powerpc64__ */

The (powerpc64 specific) Makefile may need to force a 64-bit usage (-m64 ?), presuming that such is supported from the 32 bit environment.

But the below may also/instead be involved for CROSS_TOOLCHAIN=powerpc64-gcc.


As for why the "gcc" despite the CROSS_TOOLCHAIN=powerpc64-gcc context...

The head/lib/csu/powerpc64/Makefile always attempts to force the use of "gcc":

> # XXX: See the log for r232932 as to why the above -mlongcall is needed.  Since
> # clang doesn't support -mlongcall, and testing shows a clang linked with a
> # clang-built csu segfaults, this must currently be compiled with gcc.  Once
> # clang supports -mlongcall, or we get a fixed ld, this can be revisited.
> CC:=           gcc
> COMPILER_TYPE:=        gcc

So if gcc 4.2.1 is present then by default the old gcc's assembler is used instead of the CROSS_TOOLCHAIN=powerpc64-gcc one. Otherwise gcc may not be found.

The gcc 4.2.1 behavior need not match the CROSS_TOOLCHAIN=powerpc64-gcc behavior for an otherwise-the-same command line.


===
Mark Millard
markmi at dsl-only.net



More information about the freebsd-ppc mailing list