I had written:
> So I’ve restarted the powerpc64 FreeBSD hosted tests, now based on the
> notation
>
> -Wl,-m -Wl,elf32ppc_fbsd
>
> which sys.mk’s _LDFLAGS assignment should handle okay.
Based on the system/normal gcc 4.2.1 context I’ve successfully
updated/rebuilt/booted:
A) powerpc64 10.1-STABLE -r281235 (self updated from my prior snapshot)
B) powerpc64 11.0-CURRENT -r281236
C) powerpc 11.0-CURRENT -r281236 (with -r281243 applied to fix register
save/restore)
(B) and (C) were built from (A)’s context (using a separate 11.0-CURRENT
svn-based source tree) and DESTDIR used to installkernel and installworld to
other SSD’s that were being updated.
The powerpc64-xtoolchain-gcc experimental update on a different PowerMac G5 G5
did okay as far as it got based on the notation. But it did not complete. It
will be a while before I research the following references to compiler support
routines for restoring various general purpose registers.
> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding -msoft-float
> -Os -I/usr/src/sys/boot/powerpc/boot1.chrp/../../common
> -I/usr/src/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE -m
> 32 -mcpu=powerpc -m32 -mcpu=powerpc -std=gnu99 -nostdlib -static -Wl,-N
> -Wl,-m -Wl,elf32ppc_fbsd -Wl,-m -Wl,elf32ppc_fbsd -o boot1.elf boot1.o
> ashldi3.o syncicache.o
got:
> boot1.o: In function `__puts':
> boot1.c:(.text+0xf4): undefined reference to `_restgpr_28_x'
> boot1.o: In function `__printf':
> boot1.c:(.text+0x4fc): undefined reference to `_restgpr_24_x'
> boot1.o: In function `ofw_getprop':
> boot1.c:(.text+0x628): undefined reference to `_restgpr_31_x'
> boot1.o: In function `ofw_close':
> boot1.c:(.text+0x694): undefined reference to `_restgpr_31_x'
> boot1.o: In function `dskread':
> boot1.c:(.text+0x79c): undefined reference to `_restgpr_25_x'
> boot1.o: In function `fsread':
> boot1.c:(.text+0xce4): undefined reference to `_restgpr_14_x'
> boot1.o: In function `domount':
> boot1.c:(.text+0xdb8): undefined reference to `_restgpr_28_x'
> boot1.o: In function `ofw_write.constprop.2':
> boot1.c:(.text+0xe40): undefined reference to `_restgpr_30_x'
> boot1.o: In function `putchar':
> boot1.c:(.text+0xe90): undefined reference to `_restgpr_30_x'
> boot1.o: In function `main':
> boot1.c:(.text.startup+0x528): undefined reference to `_restgpr_18_x'
> collect2: error: ld returned 1 exit status
> *** [boot1.elf] Error code 1
Before the -Wl, notation changes I did not get this far so -WL,-m
-Wl,elf32ppc_fbsd did help.
===
Mark Millard
markmi at dsl-only.net
On 2015-Apr-9, at 08:46 PM, Mark Millard <markmi at dsl-only.net> wrote:
I had written:
> I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in LDFLAGS
> would not be handled if it ended up involved:
>
> share/mk/sys.mk:_LDFLAGS = ${LDFLAGS:S/-Wl,//g} # strip -Wl,
> for LD
>
> This notation does not deal with turning the extra comma back into a space.
So I’ve restarted the powerpc64 FreeBSD hosted tests, now based on the notation
-Wl,-m -Wl,elf32ppc_fbsd
which sys.mk’s _LDFLAGS assignment should handle okay.
One test is building 11.0-CURRENT -r281236 via powerpc64-xtoolchain-gcc and the
other is building 10.1-STABLE -r281235 via the system/normal gcc 4.2.1.
As my builds take considerable time if they actually complete, it will be a
while before I can try any other variations, such as trying a gcc 4.2.1
cross-build for powerpc.
Unfortunately for the purpose at hand: I’m not set up to test any tier 1
FreeBSD environments at this time. So, for example, I can not report
observations for amd64 building elf_i386_fbsd materials. My tests may be useful
but are not sufficient of themselves to justify edits that anyone worries might
damage tier 1 build-ability.
The places I found with notation to adjust if in general the updated notation
works are:
> LDFLAGS+= -m elf32ppc_fbsd
> /usr/src/sys/boot/ofw/Makefile.inc
> LDFLAGS+= -m elf32ppc_fbsd
> /usr/src/sys/boot/uboot/Makefile.inc
> LDFLAGS+= -m elf32ppc_fbsd
> /usr/src/sys/boot/powerpc/Makefile.inc
and the tier 1 case using elf_i386_fbsd:
> LD_FLAGS+= -m elf_i386_fbsd
> /usr/src/sys/boot/i386/Makefile.inc
===
Mark Millard
markmi at dsl-only.net
Just for reference…
On 2015-Apr-9, at 07:35 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>> On Apr 9, 2015, at 7:56 PM, Mark Millard <[email protected]> wrote:
>>
>> From share/mk/bsd.README :
>>
>> LDFLAGS Additional loader flags. Passed to the loader via CC,
>> since that's used to link programs as well, so loader
>> specific flags need to be prefixed with -Wl, to work.
>>
>> But the following 3 powerpc (non-64) examples do not use the -Wl, notation:
>>
>>> LDFLAGS+= -m elf32ppc_fbsd
>>> /usr/src/sys/boot/ofw/Makefile.inc
>>
>>
>>> LDFLAGS+= -m elf32ppc_fbsd
>>> /usr/src/sys/boot/uboot/Makefile.inc
>>
>>
>>> LDFLAGS+= -m elf32ppc_fbsd
>>> /usr/src/sys/boot/powerpc/Makefile.inc
>>
>> In fact I get errors such as (for that last one when using powerpc64-gcc via
>> powerpc64-xtoolchain-gcc, executed on a powerpc64):
>>
>>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file or
>>> directory
>>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file or
>>> directory
>>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line option
>>> '-m'
>>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line option
>>> '-m'
>>>
>>> *** [boot1.elf] Error code 1
>>>
>>> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp
>>> 1 error
>>
>> I do not know if the space between -m and elf... creates a problem for -Wl,
>> use or not. I would guess that
>>
>> -Wl,-m,elf32pcc_fbsd
>>
>> is the proper notation for putting the space through to the ld variant used.
>> But I’m not to the point of testing the behavior of that yet.
>>
>>
>>
>> i386 seems to have a similar example, although I’m not using such a FreeBSD
>> environment.
>>
>>> LD_FLAGS+= -m elf_i386_fbsd
>>> /usr/src/sys/boot/i386/Makefile.inc
>>
>>
>>
>> (This note is shorter in part because figured out more context than I had
>> last time.)
>
> I think much of this is historical accident where the boot Makefiles used to
> call ld directly, then were converted to call gcc, and gcc allowed the -m
> notation like this as a historical compatibility.
>
> Do thinks still work if you use -Wl, notation?
>
> Warner
>
I have a powerpc64-xtoolchain-gcc build going now but that will take a while.
I’ll also need to try a normal one from a gcc 4.2.1 environment and I’ve not
started that yet. And I’m only set up to test powerpc64 and powerpc. The tier 1
consequences (i386 and amd64) are outside my environment.
Also I sent out another note after discovering a potential problem...
> I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in LDFLAGS
> would not be handled if it ended up involved:
>
> share/mk/sys.mk:_LDFLAGS = ${LDFLAGS:S/-Wl,//g} # strip -Wl,
> for LD
>
> This notation does not deal with turning the extra comma back into a space.
===
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]"
