Date: Tue, 10 Jan 2017 20:26:15 -0600 From: Justin Hibbits <chmeeedalf@gmail.com> To: Mark Millard <markmi@dsl-only.net> Cc: Roman Divacky <rdivacky@vlakno.cz>, Ed Maste <emaste@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] Message-ID: <4B492B88-5545-40A2-B611-6D407A00F6C5@gmail.com> In-Reply-To: <F2CE3972-6990-44CB-8D76-DEDCA92F8314@dsl-only.net> References: <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <FB7F73D7-BF8F-4477-8057-1404D27622A8@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> <20170108090307.GA3140@vlakno.cz> <1BBC8304-F9E8-4181-A287-11DD8E73B31F@dsl-only.net> <A88C2D49-FAF2-4026-B9C1-A1D3C1E39287@dsl-only.net> <20170108144133.GA19529@vlakno.cz> <5A1FE9C4-684B-43B5-AE26-03C2052E9750@dsl-only.net> <964800DA-213A-4855-A5E7-8C62823E55D5@dsl-only.net> <F2CE3972-6990-44CB-8D76-DEDCA92F8314@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark,
Thanks for all the work you've put into getting FreeBSD/powerpc*
building with clang, it's much appreciated. As time permits I'll be
reviewing and marshalling your patches in.
The fix for PR 215819 just went in (r311912), and will be MFC'd along
with all the other patches after they're all in HEAD (I chose 2 weeks
as a good ballpark frame). The others will go in as I regression test
them.
- Justin
On Jan 10, 2017, at 3:19 PM, Mark Millard wrote:
> 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 <markmi@dsl-only.net> 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 <rdivacky@vlakno.cz> 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 freebsd-toolchain@FreeBSD.org . 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
>>>
>>> _______________________________________________
>>> freebsd-toolchain@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org
>>> "
>>
>> _______________________________________________
>> freebsd-toolchain@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org
>> "
>
> _______________________________________________
> freebsd-ppc@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B492B88-5545-40A2-B611-6D407A00F6C5>