Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Apr 2015 14:44:46 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Shorter report: powerpc64-xtoolchain-gcc use fails from powerpc (non-64)
Message-ID:  <BB07709E-A5D3-458A-8ED7-61E64103A43C@dsl-only.net>

next in thread | raw e-mail | index | archive | help
Attempting to use CROSS_TOOLCHAIN=3Dpowerpc64-gcc on powerpc (non-64) =
11.0-CURRENT with TARGET_ARCH=3Dpowerpc64 gets:

> --- crti.o ---
> gcc -O2 -pipe   -I/usr/srcC/lib/csu/powerpc64/../common  =
-I/usr/srcC/lib/csu/powerpc64/../../libc/include  -mlongcall -std=3Dgnu99 =
 -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
>=20



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.@tocbase,0
> ...
>       .quad   .L._fini,.TOC.@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.@tocbase,0; \
>        .previous; \
>        .p2align 4; \
>        TYPE_ENTRY(name) \
> DOT_LABEL(name):
> ...
> #else /* !__powerpc64__ */
> #define _ENTRY(name) \
>        .text; \
>        .p2align 4; \
>        .globl  name; \
>        .type   name,@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=3Dpowerpc64-gcc.


As for why the "gcc" despite the CROSS_TOOLCHAIN=3Dpowerpc64-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:=3D           gcc
> COMPILER_TYPE:=3D        gcc

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

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


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BB07709E-A5D3-458A-8ED7-61E64103A43C>