On 2015-Apr-1, at 02:49 PM, Warner Losh <imp at bsdimp.com> wrote:
>> On Apr 1, 2015, at 2:44 PM, Mark Millard <[email protected]> wrote: >> >> 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.@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(…): > > The gcc port needs to be fixed, with changes fed upstream. The head/lib/csu/powerpc64/Makefile generated "gcc" as the command (see above). That in turn ended up as using: /usr/bin/gcc , which is the FreeBSD 4.2.1 system gcc. So no port was involved. That may be the (or a) problem: ${XCC} was not being used. >>> #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. > > Generally, we’ve not added those kinds of flags to the command line. There’s > many subtle issues in the tree trying to do that… > > Warner From a powerpc (non-64) 11.0-CURRENT boot is the following supposed to work by producing a powerpc64 appropriate result (no CROSS_TOOLCHAIN for this question)? make buildworld buildkernel KERNCONF=GENERIC64 TARGET=powerpc TARGET_ARCH=powerpc64 The standard v4.2.1 /usr/bin/gcc in a powerpc context (non-64) for that make command would produce files for TARGET_ARCH=powerpc unless the command lines specified otherwise. Notably the build environment is picking powerpc64 specific paths when appropriate, such as: lib/csu/powerpc64/Makefile so that specific Makefile is not likely to be used when powerpc64 handling is inappropriate, even executed from from a powerpc (non-64) context. A different path (and so a distinct Makefile) would be used for KERNCONF=GENERIC TARGET_ARCH=powerpc . === Mark Millard markmi at dsl-only.net _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "[email protected]"
