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]
Roman Divacky
rdivacky at vlakno.cz
Sun Jan 8 09:05:45 UTC 2017
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?
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.
Also, with all these changes. Does clang compiled kernel boot?
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 at 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 at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe at freebsd.org"
More information about the freebsd-toolchain
mailing list