date:20161208

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

2016-12-08 Thread Mark Millard

A context point that I forgot to mention. . .

I had to use WERROR= in order for buildkernel
to complete under clang 3.9.0 . Otherwise it
stopped based on:

converts between pointers to integer types with different sign 
[-Werror,-Wpointer-sign]

===
Mark Millard
markmi at dsl-only.net

On 2016-Dec-8, at 3:26 PM, Mark Millard  wrote:

[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 .


===
Mark Millard
markmi at dsl-only.net

On 2016-Dec-8, at 3:01 PM, Mark Millard  wrote:


On 2016-Dec-8, at 2:14 PM, Roman Divacky  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().
> 
> 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.
> 
> I've CCed Nathan Whitehorn. Nathan, can you take a look please?
> 
> 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
===
--- /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 = 1, usesCustomInserter = 1 in


(Roman Divacky supplied the above patch.)


# svnlite diff /usr/src/sys/modules/zfs/Makefile
Index: /usr/src/sys/modules/zfs/Makefile
===
--- /usr/src/sys/modules/zfs/Makefile   (revision 309656)
+++ /usr/src/sys/modules/zfs/Makefile   (working copy)
@@ -93,9 +93,9 @@
CFLAGS+=-I${SUNW}/common
CFLAGS+=-DBUILDING_ZFS

-.if ${MACHINE_ARCH} == "powerpc64"
-CFLAGS+=-mminimal-toc
-.endif
+#.if ${MACHINE_ARCH} == "powerpc64"
+#CFLAGS+=-mminimal-toc
+#.endif

.ifdef ZFS_DEBUG
CFLAGS+=-DDEBUG=1


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= 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= like
binutils do not end up with ld failing and buildkernel
appears to complete.

===
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.]
> 
> On 2016-Dec-8, at 10:55 AM, Roman Divacky  wrote:
> 
>> 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.
> 
> I give information for both devel/powerpc64-binutils based
> and for WITH_BINUTILS_BOOTSTRAP= based. They are different.
> 
> For using 2.25.1 of devel/powerpc64-binutils (a cross build):
> (from camera image of screen)
> 
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker390
> /boot/ker390/kernel data=0xf851a8+0x42dd98 syms=[0x8+0xd6848+0x8+0xf1137]
> /boot/entropy size=0x1000
> Booting. . .
> Kernel entry at 0x100160
> 
> Invalid memory access at   %SSR0: .001001b0   %SRR1:9000.3030
> 
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
> 
> The only options at this point are:
> 
> mac-boot
> shut-down
> 
> 
> From objdump for the above failing boot
> but with notes added:
> (Note: booting xtoolchain kernel starts at
> 00100120 instead; relative
>

[Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 buildkernel stops for: rejected assembler notation in hwpmc_e500.c

2016-12-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214904

Mark Millard  changed:

   What|Removed |Added

Summary|head -r309179 clang 3.9.0   |head -r309179 clang 3.9.0
   |TARGET_ARCH=powerpc64   |TARGET_ARCH=powerpc64
   |cross-built buildkernel |buildkernel stops for:
   |stops for: rejected |rejected assembler notation
   |assembler notation  |in hwpmc_e500.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 cross-built buildkernel stops for: rejected assembler notation

2016-12-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214904

--- Comment #2 from Mark Millard  ---
Created attachment 177812
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=177812=edit
patch for contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td

Roman Divacky provided the patch and had me test it
on am old PowerMac G5 so-called "Quad Core". It
allowed hwpmc_e500.o to be built and the build to
then continue on to other things instead of
stopping.

(The svnlite diff output is mine in order to be a
comparison against a more modern version than roman
originally used --and so mine has a closer file line
number match.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

2016-12-08 Thread Mark Millard

[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 .


===
Mark Millard
markmi at dsl-only.net

On 2016-Dec-8, at 3:01 PM, Mark Millard  wrote:


On 2016-Dec-8, at 2:14 PM, Roman Divacky  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().
> 
> 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.
> 
> I've CCed Nathan Whitehorn. Nathan, can you take a look please?
> 
> 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
===
--- /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 = 1, usesCustomInserter = 1 in


(Roman Divacky supplied the above patch.)


# svnlite diff /usr/src/sys/modules/zfs/Makefile
Index: /usr/src/sys/modules/zfs/Makefile
===
--- /usr/src/sys/modules/zfs/Makefile   (revision 309656)
+++ /usr/src/sys/modules/zfs/Makefile   (working copy)
@@ -93,9 +93,9 @@
CFLAGS+=-I${SUNW}/common
CFLAGS+=-DBUILDING_ZFS

-.if ${MACHINE_ARCH} == "powerpc64"
-CFLAGS+=-mminimal-toc
-.endif
+#.if ${MACHINE_ARCH} == "powerpc64"
+#CFLAGS+=-mminimal-toc
+#.endif

.ifdef ZFS_DEBUG
CFLAGS+=-DDEBUG=1


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= 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= like
binutils do not end up with ld failing and buildkernel
appears to complete.

===
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.]
> 
> On 2016-Dec-8, at 10:55 AM, Roman Divacky  wrote:
> 
>> 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.
> 
> I give information for both devel/powerpc64-binutils based
> and for WITH_BINUTILS_BOOTSTRAP= based. They are different.
> 
> For using 2.25.1 of devel/powerpc64-binutils (a cross build):
> (from camera image of screen)
> 
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker390
> /boot/ker390/kernel data=0xf851a8+0x42dd98 syms=[0x8+0xd6848+0x8+0xf1137]
> /boot/entropy size=0x1000
> Booting. . .
> Kernel entry at 0x100160
> 
> Invalid memory access at   %SSR0: .001001b0   %SRR1:9000.3030
> 
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
> 
> The only options at this point are:
> 
> mac-boot
> shut-down
> 
> 
> From objdump for the above failing boot
> but with notes added:
> (Note: booting xtoolchain kernel starts at
>  00100120 instead; relative
>  offsets are unchanged and the code
>  is mostly the same.)
> 
> Disassembly of section .text:
> 00100160 <.__start> mfmsr   r20
> 00100164 <.__start+0x4> li  r21,1
> 00100168 <.__start+0x8> rldimi  r20,r21,63,0
> 0010016c <.__start+0xc> mtmsrd  r20
> 00100170 <.__start+0x10> isync
>

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

2016-12-08 Thread Mark Millard


On 2016-Dec-8, at 2:14 PM, Roman Divacky  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().
> 
> 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.
> 
> I've CCed Nathan Whitehorn. Nathan, can you take a look please?
> 
> 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
===
--- /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 = 1, usesCustomInserter = 1 in


(Roman Divacky supplied the above patch.)


# svnlite diff /usr/src/sys/modules/zfs/Makefile
Index: /usr/src/sys/modules/zfs/Makefile
===
--- /usr/src/sys/modules/zfs/Makefile   (revision 309656)
+++ /usr/src/sys/modules/zfs/Makefile   (working copy)
@@ -93,9 +93,9 @@
 CFLAGS+=-I${SUNW}/common
 CFLAGS+=-DBUILDING_ZFS
 
-.if ${MACHINE_ARCH} == "powerpc64"
-CFLAGS+=-mminimal-toc
-.endif
+#.if ${MACHINE_ARCH} == "powerpc64"
+#CFLAGS+=-mminimal-toc
+#.endif
 
 .ifdef ZFS_DEBUG
 CFLAGS+=-DDEBUG=1


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= 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= like
binutils do not end up with ld failing and buildkernel
appears to complete.

===
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.]
> 
> On 2016-Dec-8, at 10:55 AM, Roman Divacky  wrote:
> 
>> 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.
> 
> I give information for both devel/powerpc64-binutils based
> and for WITH_BINUTILS_BOOTSTRAP= based. They are different.
> 
> For using 2.25.1 of devel/powerpc64-binutils (a cross build):
> (from camera image of screen)
> 
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker390
> /boot/ker390/kernel data=0xf851a8+0x42dd98 syms=[0x8+0xd6848+0x8+0xf1137]
> /boot/entropy size=0x1000
> Booting. . .
> Kernel entry at 0x100160
> 
> Invalid memory access at   %SSR0: .001001b0   %SRR1:9000.3030
> 
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
> 
> The only options at this point are:
> 
> mac-boot
> shut-down
> 
> 
> From objdump for the above failing boot
> but with notes added:
> (Note: booting xtoolchain kernel starts at
>   00100120 instead; relative
>   offsets are unchanged and the code
>   is mostly the same.)
> 
> Disassembly of section .text:
> 00100160 <.__start> mfmsr   r20
> 00100164 <.__start+0x4> li  r21,1
> 00100168 <.__start+0x8> rldimi  r20,r21,63,0
> 0010016c <.__start+0xc> mtmsrd  r20
> 00100170 <.__start+0x10> isync
> 00100174 <.__start+0x14> nop
> 00100178 <.__start+0x18> b   00100180 <.__start+0x20>
> 0010017c <.__start+0x1c> nop
> 00100180 <.__start+0x20> nop
> 00100184 <.__start+0x24> bl

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

2016-12-08 Thread Roman Divacky

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().

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.

I've CCed Nathan Whitehorn. Nathan, can you take a look please?

Thanks, Roman

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.]
> 
> On 2016-Dec-8, at 10:55 AM, Roman Divacky  wrote:
> 
> > 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.
> 
> I give information for both devel/powerpc64-binutils based
> and for WITH_BINUTILS_BOOTSTRAP= based. They are different.
> 
> For using 2.25.1 of devel/powerpc64-binutils (a cross build):
> (from camera image of screen)
> 
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker390
> /boot/ker390/kernel data=0xf851a8+0x42dd98 syms=[0x8+0xd6848+0x8+0xf1137]
> /boot/entropy size=0x1000
> Booting. . .
> Kernel entry at 0x100160
> 
> Invalid memory access at   %SSR0: .001001b0   %SRR1:9000.3030
> 
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
>  ok
> 0 >
> 
> The only options at this point are:
> 
> mac-boot
> shut-down
> 
> 
> From objdump for the above failing boot
> but with notes added:
> (Note: booting xtoolchain kernel starts at
>00100120 instead; relative
>offsets are unchanged and the code
>is mostly the same.)
> 
> Disassembly of section .text:
> 00100160 <.__start> mfmsr   r20
> 00100164 <.__start+0x4> li  r21,1
> 00100168 <.__start+0x8> rldimi  r20,r21,63,0
> 0010016c <.__start+0xc> mtmsrd  r20
> 00100170 <.__start+0x10> isync
> 00100174 <.__start+0x14> nop
> 00100178 <.__start+0x18> b   00100180 <.__start+0x20>
> 0010017c <.__start+0x1c> nop
> 00100180 <.__start+0x20> nop
> 00100184 <.__start+0x24> bl  00100190 <.__start+0x30>
> 00100188 <.__start+0x28> .long 0x0
> 0010018c <.__start+0x2c> .long 0xf8ce78
>   booting xtoolchain based kernel has: 0xfebeb8 above<<<=== note
> 00100190 <.__start+0x30> mflrr2
> 00100194 <.__start+0x34> ld  r1,0(r2)
> 00100198 <.__start+0x38> add r2,r1,r2
> 0010019c <.__start+0x3c> ld  r31,-32768(r2)
> 001001a0 <.__start+0x40> subfr31,r31,r2
> 001001a4 <.__start+0x44> ld  r1,0(r2)<<<=== !
>   booting xtoolchain based kernel has:   r1,-32760(r2) above <<<=== !
> 001001a8 <.__start+0x48> addir1,r1,16288
> 001001ac <.__start+0x4c> add r1,r1,r31
> 001001b0 <.__start+0x50> std r3,48(r1)
>   SRR0 points at the above instruction
> (I stopped comparing to the booting xtoolchain
>  based code after this.)
> 001001b4 <.__start+0x54> std r4,56(r1)
> 001001b8 <.__start+0x58> std r5,64(r1)
> 001001bc <.__start+0x5c> std r6,72(r1)
> 001001c0 <.__start+0x60> bl  001001cc <.__start+0x6c>
> 001001c4 <.__start+0x64> .long 0x0
> 001001c8 <.__start+0x68> .long 0xf84ed4
> 001001cc <.__start+0x6c> mflrr3
> 001001d0 <.__start+0x70> ld  r4,0(r3)
> 001001d4 <.__start+0x74> add r3,r4,r3
> 001001d8 <.__start+0x78> mr  r4,r31
> 001001dc <.__start+0x7c> bl  00b18ebc <.elf_reloc_self>
> 001001e0 <.__start+0x80> nop
> 001001e4 <.__start+0x84> ld  r3,48(r1)
> 001001e8 <.__start+0x88> ld  r4,56(r1)
> 001001ec <.__start+0x8c> ld  r5,64(r1)
> 001001f0 <.__start+0x90> ld  r6,72(r1)
> 001001f4 <.__start+0x94> mr  r4,r2
> 001001f8 <.__start+0x98> bl  00b1e980 <.powerpc_init>
> 001001fc <.__start+0x9c> nop
> 00100200 <.__start+0xa0> mr  r1,r3
> 00100204 <.__start+0xa4> li  r3,0
> 00100208 <.__start+0xa8> std r3,0(r1)
> 0010020c <.__start+0xac> bl  005c4af8 <.mi_startup>
> 00100210 <.__start+0xb0> nop
> 00100214 <.__start+0xb4> b   00100214 <.__start+0xb4>
> 
> 
> 
> For using WITH_BINUTILS_BOOTSTRAP= based binutils (a cross build):
> (completes for buildkernel; fails for buildworld)
> 
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker39a
> /boot/ker39a/kernel data=0xfd6318+0x42dda8 syms=[0x8+0xd6860+0x8+0xf1193]
> /boot/entropy size=0x1000
> Booting. . .
> Kernel entry at 0x100160
> 
>

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

2016-12-08 Thread Mark Millard

[I have dropped the patch related information and just have
failing-boot related information here.]

On 2016-Dec-8, at 10:55 AM, Roman Divacky  wrote:

> 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.

I give information for both devel/powerpc64-binutils based
and for WITH_BINUTILS_BOOTSTRAP= based. They are different.

For using 2.25.1 of devel/powerpc64-binutils (a cross build):
(from camera image of screen)

. . . (omitted material) . . .
Type '?' for a list of commands, 'help' for more detailed help.
OK unload
OK boot ker390
/boot/ker390/kernel data=0xf851a8+0x42dd98 syms=[0x8+0xd6848+0x8+0xf1137]
/boot/entropy size=0x1000
Booting. . .
Kernel entry at 0x100160

Invalid memory access at   %SSR0: .001001b0   %SRR1:9000.3030

Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
. . . (omitted material) . . .
 ok
0 >

The only options at this point are:

mac-boot
shut-down


>From objdump for the above failing boot
but with notes added:
(Note: booting xtoolchain kernel starts at
   00100120 instead; relative
   offsets are unchanged and the code
   is mostly the same.)

Disassembly of section .text:
00100160 <.__start> mfmsr   r20
00100164 <.__start+0x4> li  r21,1
00100168 <.__start+0x8> rldimi  r20,r21,63,0
0010016c <.__start+0xc> mtmsrd  r20
00100170 <.__start+0x10> isync
00100174 <.__start+0x14> nop
00100178 <.__start+0x18> b   00100180 <.__start+0x20>
0010017c <.__start+0x1c> nop
00100180 <.__start+0x20> nop
00100184 <.__start+0x24> bl  00100190 <.__start+0x30>
00100188 <.__start+0x28> .long 0x0
0010018c <.__start+0x2c> .long 0xf8ce78
  booting xtoolchain based kernel has: 0xfebeb8 above<<<=== note
00100190 <.__start+0x30> mflrr2
00100194 <.__start+0x34> ld  r1,0(r2)
00100198 <.__start+0x38> add r2,r1,r2
0010019c <.__start+0x3c> ld  r31,-32768(r2)
001001a0 <.__start+0x40> subfr31,r31,r2
001001a4 <.__start+0x44> ld  r1,0(r2)<<<=== !
  booting xtoolchain based kernel has:   r1,-32760(r2) above <<<=== !
001001a8 <.__start+0x48> addir1,r1,16288
001001ac <.__start+0x4c> add r1,r1,r31
001001b0 <.__start+0x50> std r3,48(r1)
  SRR0 points at the above instruction
(I stopped comparing to the booting xtoolchain
 based code after this.)
001001b4 <.__start+0x54> std r4,56(r1)
001001b8 <.__start+0x58> std r5,64(r1)
001001bc <.__start+0x5c> std r6,72(r1)
001001c0 <.__start+0x60> bl  001001cc <.__start+0x6c>
001001c4 <.__start+0x64> .long 0x0
001001c8 <.__start+0x68> .long 0xf84ed4
001001cc <.__start+0x6c> mflrr3
001001d0 <.__start+0x70> ld  r4,0(r3)
001001d4 <.__start+0x74> add r3,r4,r3
001001d8 <.__start+0x78> mr  r4,r31
001001dc <.__start+0x7c> bl  00b18ebc <.elf_reloc_self>
001001e0 <.__start+0x80> nop
001001e4 <.__start+0x84> ld  r3,48(r1)
001001e8 <.__start+0x88> ld  r4,56(r1)
001001ec <.__start+0x8c> ld  r5,64(r1)
001001f0 <.__start+0x90> ld  r6,72(r1)
001001f4 <.__start+0x94> mr  r4,r2
001001f8 <.__start+0x98> bl  00b1e980 <.powerpc_init>
001001fc <.__start+0x9c> nop
00100200 <.__start+0xa0> mr  r1,r3
00100204 <.__start+0xa4> li  r3,0
00100208 <.__start+0xa8> std r3,0(r1)
0010020c <.__start+0xac> bl  005c4af8 <.mi_startup>
00100210 <.__start+0xb0> nop
00100214 <.__start+0xb4> b   00100214 <.__start+0xb4>



For using WITH_BINUTILS_BOOTSTRAP= based binutils (a cross build):
(completes for buildkernel; fails for buildworld)

. . . (omitted material) . . .
Type '?' for a list of commands, 'help' for more detailed help.
OK unload
OK boot ker39a
/boot/ker39a/kernel data=0xfd6318+0x42dda8 syms=[0x8+0xd6860+0x8+0xf1193]
/boot/entropy size=0x1000
Booting. . .
Kernel entry at 0x100160

Invalid memory access at   %SSR0: .   %SRR1:1000.00081000

Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
. . . (omitted material) . . .
 ok
0 >

The only options at this point are:

mac-boot
shut-down

The problem here is a different code order and a matching
wrong start address that does not track the difference.
(From objdump.) Note: the same 0(r2) vs. -32760(r2) oddity
exists in the start routine as well.

Disassembly of section .text:
00100160 <.__start-0x2030> std r2,40(r1)
00100164 <.__start-0x202c> addis   r2,r2,1
00100168 <.__start-0x2028> addir2,r2,-8
0010016c <.__start-0x2024> b   00b2c8e0 <.cpu_switch>

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

2016-12-08 Thread Roman Divacky

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.

On Wed, Dec 07, 2016 at 09:52:47PM -0800, Mark Millard wrote:
> Top post of a FYI [head -r309656 powerpc64 context]:
> 
> I commented out the one -mminimal-toc use in the modules and tried
> buildkernel again (cross build).
> 
> It reached the end. But it dies immediately if I try to
> boot it after installing a copy.
> 
> This was based on:
> 
> # svnlite diff /usr/src/sys/modules/zfs/Makefile
> Index: /usr/src/sys/modules/zfs/Makefile
> ===
> --- /usr/src/sys/modules/zfs/Makefile   (revision 309656)
> +++ /usr/src/sys/modules/zfs/Makefile   (working copy)
> @@ -93,9 +93,9 @@
>  CFLAGS+=-I${SUNW}/common
>  CFLAGS+=-DBUILDING_ZFS
>  
> -.if ${MACHINE_ARCH} == "powerpc64"
> -CFLAGS+=-mminimal-toc
> -.endif
> +#.if ${MACHINE_ARCH} == "powerpc64"
> +#CFLAGS+=-mminimal-toc
> +#.endif
>  
>  .ifdef ZFS_DEBUG
>  CFLAGS+=-DDEBUG=1
> 
> as well as your .td file patch.
> 
> zfs is not in use in the configuration: it just
> uses ufs.
> 
> I'll note that I had avoided 2.47 binutils variants
> based on reported issues in powerpc land (not that
> I know the details or the powerpc64 vs. powerpc vs.
> both status of the issues).
> 
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2016-Dec-7, at 4:11 PM, Mark Millard  wrote:
> 
> On 2016-Dec-7, at 11:00 AM, Roman Divacky  wrote:
> 
> > Can the compiler you built with the patch process this file:
> > 
> > typedef int register_t;
> > #define mtpmr(reg, val) \
> >   __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> > #define mfpmr(reg)  \
> >   ( { register_t val; \
> > __asm __volatile("mfpmr %0,%1" : "=r"(val) : "K"(reg));   \
> > val; } )
> > 
> > #define  PMR_PMC016
> > 
> > int foo()
> > {
> > return mfpmr(PMR_PMC0);
> > }
> > 
> > 
> > I can compile it just fine locally. Not sure why it wouldnt work in your 
> > case.
> 
> I separately had helped with testing for bugzilla 214902
> and so had updated to head -r309656 so the context was
> different.
> 
> But I figured out the .td file related issue on powerpc64.
> 
> My means of forcing all the compiles that target powerpc64
> to use -B to pick up the alternate toolchain (since the
> bootstrap binutils ld can fail) also forced the system
> compiler to be used instead of the bootstrapped clang.
> (The SRC_CONF_ENV file that I used had the text that
> forced this.)
> 
> So my buildkernel was using an unpatched compiler when
> I tried kernel-toolchain then buildkernel.
> 
> This was visible in the .meta file part of my report on the
> problem. It showed:
> 
> > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/
> 
> 
> instead of having the path to the bootstrap compiler.
> 
> It turns out that my amd64 cross build SRC_CONF_ENV file
> also had remnants of an experiment that also happened to
> force the system compiler to be used so it would have got
> the same behavior.
> 
> Based on use of compilers that actually have your
> patch in them. . .
> 
> Your patch worked fine to let the buildkernel reach
> the next problem: use of -mminimial-toc in a kernel
> module is made but is rejected for powerpc64.
> 
> Sorry for the extra noise in reporting on your patch.
> 
> 
> Trying to find new things to report (future problems)
> by working around existing problems that are known but
> unfixed tends to have these sorts of interferences. Of
> course sometimes my workarounds might not be the best
> ones available.
> 
> This stupid mistake is probably what is going on in
> at least one bugzilla report that I submitted: So
> I've likely got more to clean up.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> Older material. . .
> 
> On Mon, Dec 05, 2016 at 05:42:28PM -0800, Mark Millard wrote:
> > On 2016-Dec-5, at 5:16 PM, Mark Millard  wrote:
> > 
> >> Well it looks like:
> >> 
> >> WITHOUT_CROSS_COMPILER=
> >> WITH_SYSTEM_COMPILER=
> >> 
> >> ignores the .td file change but
> >> 
> >> WITH_CROSS_COMPILER=
> >> WITHOUT_SYSTEM_COMPILER=
> >> 
> >> may use it.
> >> 
> >> I had accidentally used a SRC_CONF_ENV file that
> >> was of the first form.
> >> 
> >> So I've got a build going based on the 2nd form. . .
> > 
> > No such luck: same type of failure at the same point.
> > 
> > ===
> > Mark Millard
> > markmi at dsl-only.net
> > 
> > On 2016-Dec-5, at 4:05 PM, Mark Millard  wrote:
> > 
> > On 2016-Dec-5, at 8:19 AM, Roman Divacky  wrote:
> > 
> >> Can you try this patch?
> >> 
> >> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> >> ===
> >> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td(revision 288675)
> >> +++

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

[Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 buildkernel stops for: rejected assembler notation in hwpmc_e500.c

[Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 cross-built buildkernel stops for: rejected assembler notation

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

8 matches

Site Navigation

Mail list logo

Footer information