From owner-freebsd-ppc@freebsd.org Sun Jan 8 00:28:57 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47E49C95E87 for ; Sun, 8 Jan 2017 00:28:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA028135F for ; Sun, 8 Jan 2017 00:28:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18525 invoked from network); 8 Jan 2017 00:29:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 8 Jan 2017 00:29:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sat, 07 Jan 2017 19:29:01 -0500 (EST) Received: (qmail 13806 invoked from network); 8 Jan 2017 00:29:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Jan 2017 00:29:01 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id BD7E2EC914D; Sat, 7 Jan 2017 16:28:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) 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] From: Mark Millard In-Reply-To: Date: Sat, 7 Jan 2017 16:28:48 -0800 Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> References: <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <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> To: Roman Divacky , Ed Maste , Mark Linimon X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 00:28:57 -0000 [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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-7, at 3:12 PM, Mark Millard 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.] >=20 > On 2017-Jan-7, at 2:07 PM, Mark Millard = wrote: >=20 >> On 2017-Jan-7, at 12:51 AM, Roman Divacky = wrote: >>=20 >>> That's a great progress. Can you produce minimal self contained test = case that >>> exhibits this bug? And submit it to llvm bugzilla? >>>=20 >>> 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? >>>=20 >>> Thanks Mark, really great progress. >>>=20 >>> Roman >>=20 >> In attempting this I found how to control the behavior based on >> the assembler notation @toc being missing vs. being present. >>=20 >> 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. >>=20 >> FreeBSD has the option of always being explicit with @toc in order >> to avoid differences in handling of omitted notation. >>=20 >> 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. >>=20 >> [The issue of the distinction is submittable to llvm either way.] >>=20 >> Details. . . >>=20 >> For: >>=20 >> .section ".toc","aw" >> tmpstk.L: .tc tmpstk[TC],tmpstk >> . . . >> /* Set up the stack pointer */ >> ld %r1,tmpstk.L(%r2) >>=20 >> using devel/powerpc64-gcc gets: >>=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >> = locore64_simplified.S >> locore64_simplified.S: Assembler messages: >> locore64_simplified.S:80: Warning: assuming @toc on symbol >>=20 >> and produces (with R_PPC64_TOC16_DS for .toc): >>=20 >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o >>=20 >> locore64_simplified.o: file format elf64-powerpc-freebsd >>=20 >> RELOCATION RECORDS FOR [.text]: >> OFFSET TYPE VALUE=20 >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >> 0000000000000046 R_PPC64_TOC16_DS .toc >>=20 >>=20 >> RELOCATION RECORDS FOR [.toc]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 tmpstk >>=20 >>=20 >> RELOCATION RECORDS FOR [.opd]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 .__start >> 0000000000000008 R_PPC64_TOC *ABS* >>=20 >>=20 >> By contrast clang is silent (cross compiler used): >>=20 >> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>=20 >> and produces code with R_PPC64_ADDR16_DS for the .toc instead: >>=20 >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 >> locore64_simplified.o: file format elf64-powerpc-freebsd >>=20 >> RELOCATION RECORDS FOR [.text]: >> OFFSET TYPE VALUE=20 >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >> 0000000000000046 R_PPC64_ADDR16_DS .toc >>=20 >>=20 >> RELOCATION RECORDS FOR [.toc]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 tmpstk >>=20 >>=20 >> RELOCATION RECORDS FOR [.opd]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 .__start >> 0000000000000008 R_PPC64_TOC *ABS* >>=20 >>=20 >>=20 >> But for: >>=20 >> .section ".toc","aw" >> tmpstk.L: .tc tmpstk[TC],tmpstk >> . . . >> /* Set up the stack pointer */ >> ld %r1,tmpstk.L@toc(%r2) >>=20 >> (note the @toc notation) both compilers agree and use >> R_PPC64_TOC16_DS for the .toc: >>=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >> = locore64_simplified.S >>=20 >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 >> locore64_simplified.o: file format elf64-powerpc-freebsd >>=20 >> RELOCATION RECORDS FOR [.text]: >> OFFSET TYPE VALUE=20 >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >> 0000000000000046 R_PPC64_TOC16_DS .toc >>=20 >>=20 >> RELOCATION RECORDS FOR [.toc]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 tmpstk >>=20 >>=20 >> RELOCATION RECORDS FOR [.opd]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 .__start >> 0000000000000008 R_PPC64_TOC *ABS* >>=20 >>=20 >> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>=20 >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 >> locore64_simplified.o: file format elf64-powerpc-freebsd >>=20 >> RELOCATION RECORDS FOR [.text]: >> OFFSET TYPE VALUE=20 >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >> 0000000000000046 R_PPC64_TOC16_DS .toc >>=20 >>=20 >> RELOCATION RECORDS FOR [.toc]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 tmpstk >>=20 >>=20 >> RELOCATION RECORDS FOR [.opd]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 .__start >> 0000000000000008 R_PPC64_TOC *ABS* >>=20 >>=20 >>=20 >> I omitted "-f -gdwarf-2" to simplify things but with such >> clang complains about: >>=20 >> 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" >> ^ >>=20 >> (buildkernel gets such messages.) >>=20 >>=20 >> 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. >=20 > 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: >=20 > # grep "@toc[^b]" = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain_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 >=20 > devel/powerpc64-gcc and devel/powerpc64-binutils together happens to = report > on missing @toc 's. >=20 > But, of course, if some sections of code are conditionally compiled = and > excluded above they would not be listed. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net