I have added the patches to my various historical submittals
and submitted some I'd never made submittals for.
For the sys/modules/zfs/Makefile I eliminated the extra blank line
that was added in what I showed earlier for the patches.
Some of the patches are tied to allowing all 3 types of
buidlworld buildkernel contexts in Makefile* 's for
one or both of powerpc64 and powerpc:
0) system gcc 4.2.1 and (bootstrapped) system binutils
(not libc++ based)
1) devel/powerpc64-xtoolchain-gcc devel/powerpc64-gcc devel/
powerpc64-binutils
(libc++ based, no lib32)
2) system clang and devel/powerpc64-binutils or (bootstrapped)
system binutils
(One(?) driven by 3.8.0 that would not be needed for 3.9.1)
(libc++ based)
Some contexts require options that the others do not.
Some contexts require options that others do not allow and do not
need.
Some I added note to about potentially using CFLAGS.gcc+= and
CFLAGS.clang+= instead of conditional logic if the contexts allow
such to be effective.
The bugzilla numbers (if I found them all):
205455
206303
214904 (the patch allowed building but is not a complete clang/llvm
update)
215107
215681
215819
215947
215948
Generally this list excludes things for which WERROR= allows the
buildkernel attempts to complete and things related to restrictions
like avoiding lib32 for devel/powerpc64-gcc based builds.
===
Mark Millard
markmi at dsl-only.net
On 2017-Jan-8, at 9:34 PM, Mark Millard <[email protected]> wrote:
I'll note that:
Bug 214855 - head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based
cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50
[FreeBSD] 2007-07-03 internal error
means that I can not use the bootstrap binutils to do buildworld for
powerpc64.
I've confirmed that it still happens in -r311147 .
So to span both buildkernel and buildworld does require devel/
powerpc64-binutils
or the like for TARGET_ARCH=powerpc64 .
===
Mark Millard
markmi at dsl-only.net
On 2017-Jan-8, at 4:40 PM, Mark Millard <markmi at dsl-only.net>
wrote:
[I've not tried lldb yet but I have good news. . .]
Well it turns out I was wrong: after the @toc changes (now in the
TOC_REF(...) macro instead of per instruction) I can boot a kernel
built
using the bootstrap system binutils and clang as well.
devel/powerpc64-binutils or the like is not required.
It looks like bugzilla 215821 is wrong/redundant and 215819 actually
covers the issue. I will likely close 215821 after I've played around
some more.
I can build with clang 3.9.1, devel/powerpc64-xtoolchain-gcc, or gcc
4.2.1
as I have things. clang 3.9.1 based builds do not handle throwing C++
exceptions. lib32 does not work for devel/powerpc64-gcc based builds.
As stands I have head -r311147 with:
# svnlite status /usr/src/ | sort
? /usr/src/sys/amd64/conf/GENERIC-DBG
? /usr/src/sys/amd64/conf/GENERIC-NODBG
? /usr/src/sys/arm/conf/BPIM3-DBG
? /usr/src/sys/arm/conf/BPIM3-NODBG
? /usr/src/sys/arm/conf/RPI2-DBG
? /usr/src/sys/arm/conf/RPI2-NODBG
? /usr/src/sys/arm64/conf/GENERIC-DBG
? /usr/src/sys/arm64/conf/GENERIC-NODBG
? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG
? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
M /usr/src/lib/csu/powerpc64/Makefile
M /usr/src/sys/boot/ofw/Makefile.inc
M /usr/src/sys/boot/powerpc/Makefile.inc
M /usr/src/sys/boot/powerpc/kboot/Makefile
M /usr/src/sys/boot/uboot/Makefile.inc
M /usr/src/sys/conf/Makefile.powerpc
M /usr/src/sys/conf/kern.mk
M /usr/src/sys/conf/kmod.mk
M /usr/src/sys/ddb/db_main.c (Not relevant)
M /usr/src/sys/ddb/db_script.c (Not relevant)
M /usr/src/sys/modules/zfs/Makefile
M /usr/src/sys/powerpc/aim/trap_subr32.S
M /usr/src/sys/powerpc/include/asm.h
M /usr/src/sys/powerpc/ofw/ofw_machdep.c (Not relevant)
The various KERNCONF's include standard ones then adjust things.
They are not otherwise relevant.
Notes on the differences ("M" lines):
[I do not have a context to test powerpc's kboot or uboot
for powerpc or powerpc64: only PowerMacs. Those Makefile
changes were based on avoiding build errors that occurred
before the change (long ago). I've not gone back through
the armv6(/v7) and arm64 builds recently but historically
they have worked on the rpi2, bpim3, and pine64 with the
boot/uboot/Makefile.inc change in place.]
llvm/lib/Target/PowerPC/PPCInstrInfo.td is Roman D.'s
incomplete patch for the e500 instructions. It was
sufficient to let me continue.
The various Makefile*'s and *.mk's deal with:
-mlongcall (gcc) vs. not (clang)
-m elf32ppc_fbsd (old) vs. -Wl,-m -Wl,elf32ppc_fbsd (new)
-mcpu=powerpc64 and -Wa,-mppc64bridge in a Makefile
(kboot) that TARGET_ARCH=powerpc tried to build and
failed: delete the usage of these options. (No test
validation of built kboot result!)
-Wa,many for gcc vs. no-such for clang
sys/conf/kern.mk deals with:
-mllvm -disable-ppc-float-in-variadic=true (older clang)
vs.
-msoft-float (newer clang)
sys/modules/zfs/Makefile deals with:
-mminimial-toc (gcc) vs. no-such (clang)
sys/ddb/db_main.c and sys/ddb/db_script.c :
These would not be included. (They set up to execute
a built-in default script so I get information for
early boot issues from before ddb takes input.)
sys/powerpc/aim/trap_subr32.S deals with:
Have a cmp instruction be explicit by adding a "0, ".
(This is a TARGET_ARCH=powerpc issue, not a
TARGET_ARCH=powerpc64 issue.)
sys/powerpc/include/asm.h deals with:
Have TOC_REF(...) also include @toc in the notation
that results. Have a TOC_NAME_FOR_REF(...) that only
adds the .L to the name passed in and use it where
appropriate.
sys/powerpc/ofw/ofw_machdep.c :
This would not be included. (It is a PowerMac G5 specific
workaround for a openfirmware vs. FreeBSD conflict that
makes booting unreliable for standard FreeBSD builds.)
The details that are not driven by PowerMac G5 specifics
look like:
Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
===================================================================
--- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
(revision 311147)
+++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
(working copy)
@@ -2336,6 +2336,12 @@
def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
"mftb $RT, $SPR", IIC_SprMFTB>;
+def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
+ "mfpmr $RT, $PMRN", IIC_IntGeneral>;
+
+def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
+ "mtpmr $PMRN, $RS", IIC_IntGeneral>;
+
// A pseudo-instruction used to implement the read of the 64-bit
cycle counter
// on a 32-bit target.
let hasSideEffects = 1, usesCustomInserter = 1 in
Index: /usr/src/lib/csu/powerpc64/Makefile
===================================================================
--- /usr/src/lib/csu/powerpc64/Makefile (revision 311147)
+++ /usr/src/lib/csu/powerpc64/Makefile (working copy)
@@ -5,19 +5,20 @@
SRCS= crt1.c crti.S crtn.S
OBJS= ${SRCS:N*.h:R:S/$/.o/g}
OBJS+= Scrt1.o gcrt1.o
+.include <bsd.compiler.mk>
+.if ${COMPILER_TYPE} == "gcc"
CFLAGS+= -I${.CURDIR}/../common \
-I${.CURDIR}/../../libc/include \
-mlongcall
+.else
+CFLAGS+= -I${.CURDIR}/../common \
+ -I${.CURDIR}/../../libc/include
+.endif
# 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.
-.include <bsd.compiler.mk>
-.if ${COMPILER_TYPE} != "gcc"
-CC:= gcc
-COMPILER_TYPE:= gcc
-.endif
FILES= ${OBJS}
FILESMODE= ${LIBMODE}
Index: /usr/src/sys/boot/ofw/Makefile.inc
===================================================================
--- /usr/src/sys/boot/ofw/Makefile.inc (revision 311147)
+++ /usr/src/sys/boot/ofw/Makefile.inc (working copy)
@@ -2,7 +2,7 @@
.if ${MACHINE_ARCH} == "powerpc64"
CFLAGS+= -m32 -mcpu=powerpc
-LDFLAGS+= -m elf32ppc_fbsd
+LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd
.endif
.include "../Makefile.inc"
Index: /usr/src/sys/boot/powerpc/Makefile.inc
===================================================================
--- /usr/src/sys/boot/powerpc/Makefile.inc (revision 311147)
+++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy)
@@ -2,6 +2,7 @@
.if ${MACHINE_ARCH} == "powerpc64"
CFLAGS+= -m32 -mcpu=powerpc
+LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd
.endif
.include "../Makefile.inc"
Index: /usr/src/sys/boot/powerpc/kboot/Makefile
===================================================================
--- /usr/src/sys/boot/powerpc/kboot/Makefile (revision 311147)
+++ /usr/src/sys/boot/powerpc/kboot/Makefile (working copy)
@@ -68,8 +68,6 @@
LIBFICL= ${.OBJDIR}/../../ficl/libficl.a
.endif
-CFLAGS+= -mcpu=powerpc64
-
# Always add MI sources
.PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
.include "${.CURDIR}/../../common/Makefile.inc"
@@ -85,9 +83,6 @@
LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc
-# 64-bit bridge extensions
-CFLAGS+= -Wa,-mppc64bridge
-
# Pull in common loader code
#.PATH: ${.CURDIR}/../../ofw/common
#.include "${.CURDIR}/../../ofw/common/Makefile.inc"
Index: /usr/src/sys/boot/uboot/Makefile.inc
===================================================================
--- /usr/src/sys/boot/uboot/Makefile.inc (revision 311147)
+++ /usr/src/sys/boot/uboot/Makefile.inc (working copy)
@@ -2,7 +2,7 @@
.if ${MACHINE_ARCH} == "powerpc64"
CFLAGS+= -m32 -mcpu=powerpc
-LDFLAGS+= -m elf32ppc_fbsd
+LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd
.endif
.include "../Makefile.inc"
Index: /usr/src/sys/conf/Makefile.powerpc
===================================================================
--- /usr/src/sys/conf/Makefile.powerpc (revision 311147)
+++ /usr/src/sys/conf/Makefile.powerpc (working copy)
@@ -39,7 +39,11 @@
# Force __SPE__, since the builtin will be removed later with -mno-spe
CFLAGS+= -mabi=spe -D__SPE__
.endif
+.if ${COMPILER_TYPE} == "gcc"
CFLAGS+= -msoft-float -Wa,-many
+.else
+CFLAGS+= -msoft-float
+.endif
# Build position-independent kernel
CFLAGS+= -fPIC
Index: /usr/src/sys/conf/kern.mk
===================================================================
--- /usr/src/sys/conf/kern.mk (revision 311147)
+++ /usr/src/sys/conf/kern.mk (working copy)
@@ -162,7 +162,11 @@
#
.if ${MACHINE_CPUARCH} == "powerpc"
CFLAGS+= -mno-altivec
+.if ${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} < 30800
CFLAGS.clang+= -mllvm -disable-ppc-float-in-variadic=true
+.else
+CFLAGS.clang+= -msoft-float
+.endif
CFLAGS.gcc+= -msoft-float
INLINE_LIMIT?= 15000
.endif
Index: /usr/src/sys/conf/kmod.mk
===================================================================
--- /usr/src/sys/conf/kmod.mk (revision 311147)
+++ /usr/src/sys/conf/kmod.mk (working copy)
@@ -147,8 +147,12 @@
.endif
.if ${MACHINE_CPUARCH} == powerpc
+.if ${COMPILER_TYPE} == "gcc"
CFLAGS+= -mlongcall -fno-omit-frame-pointer
+.else
+CFLAGS+= -fno-omit-frame-pointer
.endif
+.endif
.if ${MACHINE_CPUARCH} == mips
CFLAGS+= -G0 -fno-pic -mno-abicalls -mlong-calls
Index: /usr/src/sys/modules/zfs/Makefile
===================================================================
--- /usr/src/sys/modules/zfs/Makefile (revision 311147)
+++ /usr/src/sys/modules/zfs/Makefile (working copy)
@@ -93,9 +93,16 @@
CFLAGS+=-I${SUNW}/common
CFLAGS+=-DBUILDING_ZFS
+
.if ${MACHINE_ARCH} == "powerpc64"
+.include <bsd.compiler.mk>
+.if ${COMPILER_TYPE} == "gcc"
+# gcc421 requires the -mminimal-toc .
+# But clang 3.9.1 disallows it and does not need it.
+# more modern gcc's allow it.
CFLAGS+=-mminimal-toc
.endif
+.endif
.ifdef ZFS_DEBUG
CFLAGS+=-DDEBUG=1
Index: /usr/src/sys/powerpc/aim/trap_subr32.S
===================================================================
--- /usr/src/sys/powerpc/aim/trap_subr32.S (revision 311147)
+++ /usr/src/sys/powerpc/aim/trap_subr32.S (working copy)
@@ -406,7 +406,7 @@
mtctr %r1 /* load counter */
im1:
lwzu %r1, 8(%r2) /* get next pte */
- cmp 0, %r1, %r3 /* see if found pte */
+ cmp 0, 0, %r1, %r3 /* see if found pte */
bdnzf 2, im1 /* dec count br if cmp ne and if
* count not zero */
bne instr_sec_hash /* if not found set up second hash
Index: /usr/src/sys/powerpc/include/asm.h
===================================================================
--- /usr/src/sys/powerpc/include/asm.h (revision 311147)
+++ /usr/src/sys/powerpc/include/asm.h (working copy)
@@ -89,10 +89,11 @@
name:
#ifdef __powerpc64__
-#define TOC_REF(name) __CONCAT(.L,name)
+#define TOC_NAME_FOR_REF(name) __CONCAT(.L,name)
+#define TOC_REF(name) TOC_NAME_FOR_REF(name)@toc
#define TOC_ENTRY(name) \
.section ".toc","aw"; \
- TOC_REF(name): \
+ TOC_NAME_FOR_REF(name): \
.tc name[TC],name
#endif
===
Mark Millard
markmi at dsl-only.net
On 2017-Jan-8, at 6:41 AM, Roman Divacky <[email protected]> wrote:
Mark,
Would you be interested in trying lld? It has some support for ppc/
ppc64, which
is probably quite incomplete but it would be nice to know what
exactly is
missing.
We also have some people (emaste@, davide@) that have non-trivial
lld knowledge
so perhaps progress can be achieved on this side easily?
Roman
On Sun, Jan 08, 2017 at 02:57:11AM -0800, Mark Millard wrote:
[I forgot to indicate that I still can not use the system
bootstrapped
ld command and so there is a reason that I used devel/powerpc64-
binutils.]
On 2017-Jan-8, at 2:24 AM, Mark Millard <markmi at dsl-only.net>
wrote:
On 2017-Jan-8, at 1:03 AM, Roman Divacky <rdivacky at vlakno.cz>
wrote:
I think we should add the @toc notations to all the places where
it's needed.
Can you submit such a patch (perhaps with the one for adding 0 to
the cmp
instruction) so they can be committed to FreeBSD repo?
In order to test I added @toc to each of the 10 instructions instead
of adjusting the macros so that instructions would automatically
get the notation but other (what are now) TOC_REF(...) usage would
not that should not.
I suspect Nathan and Justin might prefer a more automatic
alternative so that TOC_REF(...) in an instruction would
be sufficient without an explicit @toc in the instruction.
I'll see about switching to such code before providing a
patch. I'd include the "0, " update to the cmp instruction.
But adding @toc's in those instructions (with prior workarounds
as well) did allow me to build a bootable system based on using
devel/powerpc64-binutils and clang 3.9.1 for both buildworld
and buildkernel --still using clang's internal assembler.
One issue is that clang does not support (or need) the
-mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1
requires it. For sys/modules/zfs/Makefile my source
currently does not support gcc 4.2.1 without editing.
As I remember devel/powerpc64-gcc
(devel/powerpc64-xtoolchain-gcc) does not require the
-mminimal-toc either. But devel/powerpc64-gcc does
allow -mminimal-toc so it can be a clang vs. gcc based
choice.
I might also deal with that before providing patches.
Note: -mlongcall was also not needed nor used for clang.
(Still used for gcc.)
sys/boot/powerpc/kboot/Makefile has a -mcpu=powerpc64
and -Wa,-mppc64bridge that I eliminated (they messed up
32-bit powerpc builds) but I've no way to test kboot that
I know of. This patch might be rejected.
Remember that I got this far in part by using your partial
e500-instructions patch. I can provide my variant that
is a diff with -r311147 instead of an older place in the
history. But it would be incomplete coverage of those 2
instructions in clang.
Also I build with a workaround for PowerMac G5 boot
reliability since OpenFirmware and FreeBSD interact
badly at times on PowerMac G5's. This I would not
provide as it is PowerMac G5 specific.
If gnu as warns and llvm assembler does the wrong thing without
@toc and both
do the correct thing with @toc I think it's an obvious decision.
My choice would be to supply the @toc notation in some way,
not necessarily the form I used for the initial test.
Also, with all these changes. Does clang compiled kernel boot?
The PowerMac G5 so-called "Quad Core" that I currently have access
to is now running from buildworld and buildkernel based on
devel/powerpc64-binutils and clang 3.9.1 :
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,
1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017
markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/
powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc
FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based
on LLVM 3.9.1)
. . .
# uname -apKU
FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat
Jan 7 16:55:01 PST 2017 markmi@FreeBSDx64:/usr/obj/
powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/
sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 1200019
I've built about a dozen ports on it after booting but I've not
done a self-hosted buildworld buildkernel yet.
[Note: Anything dependent on throwing C++ exceptions in
code generated by clang++ 3.9.1 is broken.]
I should have been explicit:
I still can not use the system bootstrapped ld command
and such binutils for buildkernel and so there is a
reason that I used devel/powerpc64-binutils instead.
Thus even with my patches clang 3.9.1 would not be ready
for general use or for a default way of building. I
have to have a tailored SRC_ENV_CONF file or the like
still --and a port built and installed.
[On a powerpc64 system devel/binutils could be used.]
There is also the issue with throwing C++ exceptions
in code when clang 3.9.1 was the code generator used.
===
Mark Millard
markmi at dsl-only.net
On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote:
[Top post about FreeBSD bugzilla 215819 and llvm bugzilla
31574 submittals for the issue involved.]
My guess is that FreeBSD will view this as a kernel
source code issue and not as a toolchain issue. But
it is only a guess on my part.
I have submitted llvm bugzilla 31574 for this issue. It
includes example .S file content that shows the "problem"
in the generated .o file (form FreeBSD's view point).
(I've no clue how llvm views its criteria relative to this
mismatch with gcc/binutils.)
Because FreeBSD source code changes (being explicit about
@toc) avoid the distinction between clang and gcc/binutils
I've not added 31574 to the Depends on list for llvm 25780
(the FreeBSD system compiler issues META entry in llvm).
Someone with official status for FreeBSD could add 31574 to
llvm's 25780 if FreeBSD wants to push llvm to match
gcc/binutils for "@toc notation missing".
Otherwise this is a kernel source code issue (as I would
guess) and not a toolchain issue.
Ed Maste or someone like that likely would make the final
decision.
I've added to FreeBSD Bugzilla 215819 the new information,
including the simple example .S file content that shows the
problem in the generated .o file. (Comments #3 and #4
have the new material.)
My guess is that FreeBSD Bugzilla 215819 should no longer
be assigned to [email protected] . Instead it
would be a powerpc64 kernel source code issue if I'm right.
Ed Maste or someone like that likely would make this final
decision as well.
===
Mark Millard
markmi at dsl-only.net
On 2017-Jan-7, at 3:12 PM, Mark Millard <markmi at dsl-only.net>
wrote:
[I've supplied a list of places that adding @toc notation should
make clang 3.9.1 targeting powerpc64 do the right thing for
this issue.]
On 2017-Jan-7, at 2:07 PM, Mark Millard <markmi at dsl-only.net>
wrote:
On 2017-Jan-7, at 12:51 AM, Roman Divacky <rdivacky at
vlakno.cz> wrote:
That's a great progress. Can you produce minimal self contained
test case that
exhibits this bug? And submit it to llvm bugzilla?
Also, clang3.9 defaults to using it's own internal asm, what
happens if you
add -no-integrated-as to CFLAGS and recompile the kernel? That
should remove
this llvm assembly problem. Does it boot?
Thanks Mark, really great progress.
Roman
In attempting this I found how to control the behavior based on
the assembler notation @toc being missing vs. being present.
If llvm should change is strongly tied to llvm's criteria for
gcc compatibility relative to filling-in/defaulting omitted
@toc's in the assembler notation.
FreeBSD has the option of always being explicit with @toc in order
to avoid differences in handling of omitted notation.
So I've no clue if FreebSD wants to claim that a llvm change
is a requirement for using clang as the powerpc64 system compiler.
[The issue of the distinction is submittable to llvm either way.]
Details. . .
For:
.section ".toc","aw"
tmpstk.L: .tc tmpstk[TC],tmpstk
. . .
/* Set up the stack pointer */
ld %r1,tmpstk.L(%r2)
using devel/powerpc64-gcc gets:
# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc
\ -c
\ -x
assembler-with-cpp
\ -pipe
\
locore64_simplified
.S
locore64_simplified.S: Assembler messages:
locore64_simplified.S:80: Warning: assuming @toc on symbol
and produces (with R_PPC64_TOC16_DS for .toc):
# /usr/local/powerpc64-freebsd/bin/objdump -r
locore64_simplified.o
locore64_simplified.o: file format elf64-powerpc-freebsd
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000
0000000000000046 R_PPC64_TOC16_DS .toc
RELOCATION RECORDS FOR [.toc]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_ADDR64 tmpstk
RELOCATION RECORDS FOR [.opd]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_ADDR64 .__start
0000000000000008 R_PPC64_TOC *ABS*
By contrast clang is silent (cross compiler used):
# /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/
tmp/usr/bin/cc
\ -target
powerpc64-unknown-freebsd12.0
\ --sysroot
=/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/
tmp
\ -B
/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/
tmp/usr/bin \
-c
\ -x
assembler-with-cpp
\ -pipe
\ locore64_simplified
.S
and produces code with R_PPC64_ADDR16_DS for the .toc instead:
# /usr/local/powerpc64-freebsd/bin/objdump -r
locore64_simplified.o | more
locore64_simplified.o: file format elf64-powerpc-freebsd
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000
0000000000000046 R_PPC64_ADDR16_DS .toc
RELOCATION RECORDS FOR [.toc]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_ADDR64 tmpstk
RELOCATION RECORDS FOR [.opd]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_ADDR64 .__start
0000000000000008 R_PPC64_TOC *ABS*
But for:
.section ".toc","aw"
tmpstk.L: .tc tmpstk[TC],tmpstk
. . .
/* Set up the stack pointer */
ld %r1,tmpstk.L@toc(%r2)
(note the @toc notation) both compilers agree and use
R_PPC64_TOC16_DS for the .toc:
# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc
\ -c
\ -x
assembler-with-cpp
\ -pipe
\
locore64_simplified
.S
# /usr/local/powerpc64-freebsd/bin/objdump -r
locore64_simplified.o | more
locore64_simplified.o: file format elf64-powerpc-freebsd
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000
0000000000000046 R_PPC64_TOC16_DS .toc
RELOCATION RECORDS FOR [.toc]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_ADDR64 tmpstk
RELOCATION RECORDS FOR [.opd]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_ADDR64 .__start
0000000000000008 R_PPC64_TOC *ABS*
# /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/
tmp/usr/bin/cc
\ -target
powerpc64-unknown-freebsd12.0
\ --sysroot
=/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/
tmp
\ -B
/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/
tmp/usr/bin \
-c
\ -x
assembler-with-cpp
\ -pipe
\ locore64_simplified
.S
# /usr/local/powerpc64-freebsd/bin/objdump -r
locore64_simplified.o | more
locore64_simplified.o: file format elf64-powerpc-freebsd
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000
0000000000000046 R_PPC64_TOC16_DS .toc
RELOCATION RECORDS FOR [.toc]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_ADDR64 tmpstk
RELOCATION RECORDS FOR [.opd]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_ADDR64 .__start
0000000000000008 R_PPC64_TOC *ABS*
I omitted "-f -gdwarf-2" to simplify things but with such
clang complains about:
locore64_simplified.S:36:2: warning: DWARF2 only supports one
section per compilation unit
.section ".toc","aw"
^
locore64_simplified.S:47:2: warning: DWARF2 only supports one
section per compilation unit
.section ".opd","aw"
^
(buildkernel gets such messages.)
I expect I can simplify the .S code more than I have so far but
I figured I'd report the discovery of the choice FreeBSD needs
to make for powerpc64 for if llvm changes are to be required
vs. not.
The following should be a list of the places that adding @toc usage
would fix some things for using clang 3.9.1 to target powerpc64:
# grep "@toc[^b]" /root/sys_typescripts/
typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolchain_kernel
-amd64-host-2017-01-03:23:48:41 | more
/usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc
on symbol
/usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming
@toc on symbol
/usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming
@toc on symbol
/usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc
on symbol
/usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc
on symbol
/usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc
on symbol
/usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc
on symbol
/usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc
on symbol
/usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc
on symbol
/usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming
@toc on symbol
devel/powerpc64-gcc and devel/powerpc64-binutils together happens
to report
on missing @toc 's.
But, of course, if some sections of code are conditionally
compiled and
excluded above they would not be listed.
===
Mark Millard
markmi at dsl-only.net
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[email protected]
"
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[email protected]
"
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"
