> On Apr 1, 2015, at 4:37 PM, Mark Millard <mar...@dsl-only.net> wrote:
>
>
> 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 <mar...@dsl-only.net> 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.That’s an interesting hole. It should be. >>>> #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 This should work, modulo broken compilers. > 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. Ah, so it is a ‘cross build’ situation... > 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 . The hack in that Makefile likely needs to be revisited. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
