Date: Thu, 8 Dec 2016 15:26:42 -0800 From: Mark Millard <markmi@dsl-only.net> To: Roman Divacky <rdivacky@vlakno.cz>, Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com>, 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. . . Message-ID: <20480337-3CF7-4ED4-AB55-ADE18A3F0F75@dsl-only.net> In-Reply-To: <29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net> <D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net> <20161207190057.GA58950@vlakno.cz> <E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net> <CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net> <20161208185541.GA33364@vlakno.cz> <E49F7EE4-7A62-4601-98DC-4C4791B7158D@dsl-only.net> <20161208221452.GA42380@vlakno.cz> <29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[Top post noting a systematic stupid typo of mine.]
I keep typing 2.47 instead of 2.27 for devel/binutils
and devel/powerpc64-binutils .
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Dec-8, at 3:01 PM, Mark Millard <markmi@dsl-only.net> wrote:
On 2016-Dec-8, at 2:14 PM, Roman Divacky <rdivacky@vlakno.cz> wrote:
> I believe the code comes from sys/powerpc/aim/locore64.S and if you =
compare
> the different values from the disssembly with the .S code you can see
> it's __tocbase and TOC_REF().
>=20
> I wonder if the assembly has the -mminimal-toc knowledge hardcoded in =
somehow.
> I am not sure what expectations the locore64.S has about the kernel =
layout that
> we're probably breaking.
>=20
> I've CCed Nathan Whitehorn. Nathan, can you take a look please?
>=20
> Thanks, Roman
For Nathan's reference about the context:
I got to the point of having a clang 3.9.0 buildkernel finish
for targeting powerpc64. But it does not boot.
I'm working from head -r309656 with the following patches:
(ignoring my usual PowerMac G5 powerpc64 booting hack related
materials that I've had in place for a long time)
# svnlite diff /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =
(revision 309656)
+++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working =
copy)
@@ -2300,6 +2300,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 =3D 1, usesCustomInserter =3D 1 in
(Roman Divacky supplied the above patch.)
# svnlite diff /usr/src/sys/modules/zfs/Makefile
Index: /usr/src/sys/modules/zfs/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/sys/modules/zfs/Makefile (revision 309656)
+++ /usr/src/sys/modules/zfs/Makefile (working copy)
@@ -93,9 +93,9 @@
CFLAGS+=3D-I${SUNW}/common
CFLAGS+=3D-DBUILDING_ZFS
-.if ${MACHINE_ARCH} =3D=3D "powerpc64"
-CFLAGS+=3D-mminimal-toc
-.endif
+#.if ${MACHINE_ARCH} =3D=3D "powerpc64"
+#CFLAGS+=3D-mminimal-toc
+#.endif
.ifdef ZFS_DEBUG
CFLAGS+=3D-DDEBUG=3D1
This last just avoids that clang 3.9.0 for targeting
powerpc64 rejects the -mminimal-toc command line option.
It being missing did not cause the buildkernel to stop.
Note: I have booted with clang 3.9.0 based buildworld
materials. (But C++ exception handling is still messed
up so code dependent on C++ exceptions happening needs
to be avoided.) I've had to avoid both
WITH_BINUTILS_BOOTSTRAP=3D like binutils and 2.47 variants
of devel/powerpc64-binutils or devel/binutils: I use
older 2.25.1 devel/powerpc64-binutils or devel/binutils
(on the powerpc64 itself).
However for buildkernel WITH_BINUTILS_BOOTSTRAP=3D like
binutils do not end up with ld failing and buildkernel
appears to complete.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Older material:
On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote:
> [I have dropped the patch related information and just have
> failing-boot related information here.]
>=20
> On 2016-Dec-8, at 10:55 AM, Roman Divacky <rdivacky at vlakno.cz> =
wrote:
>=20
>> Can you try to investigate why it dies? I am not convinced =
-mminimal-toc
>> would result in a boot failure. I think the kernel would fail to =
link.
>=20
> I give information for both devel/powerpc64-binutils based
> and for WITH_BINUTILS_BOOTSTRAP=3D based. They are different.
>=20
> For using 2.25.1 of devel/powerpc64-binutils (a cross build):
> (from camera image of screen)
>=20
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker390
> /boot/ker390/kernel data=3D0xf851a8+0x42dd98 =
syms=3D[0x8+0xd6848+0x8+0xf1137]
> /boot/entropy size=3D0x1000
> Booting. . .
> Kernel entry at 0x100160
>=20
> Invalid memory access at %SSR0: 00000000.001001b0 =
%SRR1:90000000.00003030
>=20
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
>=20
> The only options at this point are:
>=20
> mac-boot
> shut-down
>=20
>=20
> =46rom objdump for the above failing boot
> but with notes added:
> (Note: booting xtoolchain kernel starts at
> 0000000000100120 instead; relative
> offsets are unchanged and the code
> is mostly the same.)
>=20
> Disassembly of section .text:
> 0000000000100160 <.__start> mfmsr r20
> 0000000000100164 <.__start+0x4> li r21,1
> 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010016c <.__start+0xc> mtmsrd r20
> 0000000000100170 <.__start+0x10> isync
> 0000000000100174 <.__start+0x14> nop
> 0000000000100178 <.__start+0x18> b 0000000000100180 =
<.__start+0x20>
> 000000000010017c <.__start+0x1c> nop
> 0000000000100180 <.__start+0x20> nop
> 0000000000100184 <.__start+0x24> bl 0000000000100190 =
<.__start+0x30>
> 0000000000100188 <.__start+0x28> .long 0x0
> 000000000010018c <.__start+0x2c> .long 0xf8ce78 =20
> booting xtoolchain based kernel has: 0xfebeb8 above <<<=3D=3D=3D =
note
> 0000000000100190 <.__start+0x30> mflr r2
> 0000000000100194 <.__start+0x34> ld r1,0(r2)
> 0000000000100198 <.__start+0x38> add r2,r1,r2
> 000000000010019c <.__start+0x3c> ld r31,-32768(r2)
> 00000000001001a0 <.__start+0x40> subf r31,r31,r2
> 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D=
!!!!!
> booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D =
!!!!!
> 00000000001001a8 <.__start+0x48> addi r1,r1,16288
> 00000000001001ac <.__start+0x4c> add r1,r1,r31
> 00000000001001b0 <.__start+0x50> std r3,48(r1)
> SRR0 points at the above instruction
> (I stopped comparing to the booting xtoolchain
> based code after this.)
> 00000000001001b4 <.__start+0x54> std r4,56(r1)
> 00000000001001b8 <.__start+0x58> std r5,64(r1)
> 00000000001001bc <.__start+0x5c> std r6,72(r1)
> 00000000001001c0 <.__start+0x60> bl 00000000001001cc =
<.__start+0x6c>
> 00000000001001c4 <.__start+0x64> .long 0x0
> 00000000001001c8 <.__start+0x68> .long 0xf84ed4
> 00000000001001cc <.__start+0x6c> mflr r3
> 00000000001001d0 <.__start+0x70> ld r4,0(r3)
> 00000000001001d4 <.__start+0x74> add r3,r4,r3
> 00000000001001d8 <.__start+0x78> mr r4,r31
> 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc =
<.elf_reloc_self>
> 00000000001001e0 <.__start+0x80> nop
> 00000000001001e4 <.__start+0x84> ld r3,48(r1)
> 00000000001001e8 <.__start+0x88> ld r4,56(r1)
> 00000000001001ec <.__start+0x8c> ld r5,64(r1)
> 00000000001001f0 <.__start+0x90> ld r6,72(r1)
> 00000000001001f4 <.__start+0x94> mr r4,r2
> 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 =
<.powerpc_init>
> 00000000001001fc <.__start+0x9c> nop
> 0000000000100200 <.__start+0xa0> mr r1,r3
> 0000000000100204 <.__start+0xa4> li r3,0
> 0000000000100208 <.__start+0xa8> std r3,0(r1)
> 000000000010020c <.__start+0xac> bl 00000000005c4af8 =
<.mi_startup>
> 0000000000100210 <.__start+0xb0> nop
> 0000000000100214 <.__start+0xb4> b 0000000000100214 =
<.__start+0xb4>
>=20
>=20
>=20
> For using WITH_BINUTILS_BOOTSTRAP=3D based binutils (a cross build):
> (completes for buildkernel; fails for buildworld)
>=20
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker39a
> /boot/ker39a/kernel data=3D0xfd6318+0x42dda8 =
syms=3D[0x8+0xd6860+0x8+0xf1193]
> /boot/entropy size=3D0x1000
> Booting. . .
> Kernel entry at 0x100160
>=20
> Invalid memory access at %SSR0: 00000000.00000000 =
%SRR1:10000000.00081000
>=20
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
>=20
> The only options at this point are:
>=20
> mac-boot
> shut-down
>=20
> The problem here is a different code order and a matching
> wrong start address that does not track the difference.
> (=46rom objdump.) Note: the same 0(r2) vs. -32760(r2) oddity
> exists in the start routine as well.
>=20
> Disassembly of section .text:
> 0000000000100160 <.__start-0x2030> std r2,40(r1)
> 0000000000100164 <.__start-0x202c> addis r2,r2,1
> 0000000000100168 <.__start-0x2028> addi r2,r2,-8
> 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 =
<.cpu_switch>
> 0000000000100170 <.__start-0x2020> std r2,40(r1)
> 0000000000100174 <.__start-0x201c> addis r2,r2,1
> 0000000000100178 <.__start-0x2018> addi r2,r2,-8
> 000000000010017c <.__start-0x2014> b 0000000000ade6c8 =
<.sf_buf_alloc>
> 0000000000100180 <.__start-0x2010> std r2,40(r1)
> 0000000000100184 <.__start-0x200c> addis r2,r2,1
> 0000000000100188 <.__start-0x2008> addi r2,r2,-8
> 000000000010018c <.__start-0x2004> b 0000000000a83f78 =
<.vm_fault_hold>
> 0000000000100190 <.__start-0x2000> std r2,40(r1)
> 0000000000100194 <.__start-0x1ffc> addis r2,r2,1
> 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8
> 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 =
<.fill_regs32>
> 00000000001001a0 <.__start-0x1ff0> std r2,40(r1)
> 00000000001001a4 <.__start-0x1fec> addis r2,r2,1
> 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8
> 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 =
<.casueword32>
> 00000000001001b0 <.__start-0x1fe0> std r2,40(r1)
> 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1
> 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8
> 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 =
<.kmap_free_wakeup>
> . . .
> 0000000000102190 <.__start> mfmsr r20
> 0000000000102194 <.__start+0x4> li r21,1
> 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010219c <.__start+0xc> mtmsrd r20
> 00000000001021a0 <.__start+0x10> isync
> 00000000001021a4 <.__start+0x14> nop
> 00000000001021a8 <.__start+0x18> b 00000000001021b0 =
<.__start+0x20>
> 00000000001021ac <.__start+0x1c> nop
> 00000000001021b0 <.__start+0x20> nop
> 00000000001021b4 <.__start+0x24> bl 00000000001021c0 =
<.__start+0x30>
> 00000000001021b8 <.__start+0x28> .long 0x0
> 00000000001021bc <.__start+0x2c> .long 0xfc8e48
> 00000000001021c0 <.__start+0x30> mflr r2
> 00000000001021c4 <.__start+0x34> ld r1,0(r2)
> 00000000001021c8 <.__start+0x38> add r2,r1,r2
> 00000000001021cc <.__start+0x3c> ld r31,-32768(r2)
> 00000000001021d0 <.__start+0x40> subf r31,r31,r2
> 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. =
-32760 oddity!!!
> 00000000001021d8 <.__start+0x48> addi r1,r1,16288
> 00000000001021dc <.__start+0x4c> add r1,r1,r31
> 00000000001021e0 <.__start+0x50> std r3,48(r1)
> 00000000001021e4 <.__start+0x54> std r4,56(r1)
> 00000000001021e8 <.__start+0x58> std r5,64(r1)
> 00000000001021ec <.__start+0x5c> std r6,72(r1)
> 00000000001021f0 <.__start+0x60> bl 00000000001021fc =
<.__start+0x6c>
> 00000000001021f4 <.__start+0x64> .long 0x0
> 00000000001021f8 <.__start+0x68> .long 0xfd4014
> 00000000001021fc <.__start+0x6c> mflr r3
> 0000000000102200 <.__start+0x70> ld r4,0(r3)
> 0000000000102204 <.__start+0x74> add r3,r4,r3
> 0000000000102208 <.__start+0x78> mr r4,r31
> 000000000010220c <.__start+0x7c> bl 0000000000101a20 =
<begin+0x1a20>
> 0000000000102210 <.__start+0x80> ld r2,40(r1)
> 0000000000102214 <.__start+0x84> ld r3,48(r1)
> 0000000000102218 <.__start+0x88> ld r4,56(r1)
> 000000000010221c <.__start+0x8c> ld r5,64(r1)
> 0000000000102220 <.__start+0x90> ld r6,72(r1)
> 0000000000102224 <.__start+0x94> mr r4,r2
> 0000000000102228 <.__start+0x98> bl 00000000001019a0 =
<begin+0x19a0>
> 000000000010222c <.__start+0x9c> ld r2,40(r1)
> 0000000000102230 <.__start+0xa0> mr r1,r3
> 0000000000102234 <.__start+0xa4> li r3,0
> 0000000000102238 <.__start+0xa8> std r3,0(r1)
> 000000000010223c <.__start+0xac> bl 00000000005c6b28 =
<.mi_startup>
> 0000000000102240 <.__start+0xb0> nop
> 0000000000102244 <.__start+0xb4> b 0000000000102244 =
<.__start+0xb4>
>=20
>=20
> Who is most appropriate to send such information to for powerpc64?
>=20
> =3D=3D=3D
> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20480337-3CF7-4ED4-AB55-ADE18A3F0F75>