From owner-freebsd-ppc@FreeBSD.ORG  Tue Mar 10 20:12:03 2015
Return-Path: <owner-freebsd-ppc@FreeBSD.ORG>
Delivered-To: freebsd-ppc@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 9CF1F63D
 for <freebsd-ppc@freebsd.org>; Tue, 10 Mar 2015 20:12:03 +0000 (UTC)
Received: from asp.reflexion.net (outbound-242.asp.reflexion.net
 [69.84.129.242])
 (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 32E5F8EC
 for <freebsd-ppc@freebsd.org>; Tue, 10 Mar 2015 20:12:02 +0000 (UTC)
Received: (qmail 2380 invoked from network); 10 Mar 2015 20:11:54 -0000
Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2)
 by 0 (rfx-qmail) with SMTP; 10 Mar 2015 20:11:54 -0000
Received: by mail-cs-02.app.dca.reflexion.local
 (Reflexion email security v7.40.1) with SMTP;
 Tue, 10 Mar 2015 16:11:54 -0400 (EDT)
Received: (qmail 31390 invoked from network); 10 Mar 2015 20:11:54 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
 by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP;
 10 Mar 2015 20:11:54 -0000
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net
 [67.189.19.145])
 by iron2.pdx.net (Postfix) with ESMTPSA id 789801C43AC;
 Tue, 10 Mar 2015 13:11:49 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: powerpc64 10.1-STABLE [WITH_DEBUG] context;
 cmake's /usr/local/bin/ctest broken but graphics/png configuration
 defaults use it
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net>
Date: Tue, 10 Mar 2015 13:11:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <21202F99-B759-4888-8C7E-5F65D4346F96@dsl-only.net>
References: <A57B3364-B573-45A1-8970-D0E69DE0671A@dsl-only.net>
 <54FC7D92.3010405@freebsd.org>
 <E3BADD6E-89CD-415E-8ECE-753568C71A30@dsl-only.net>
 <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net>
To: Nathan Whitehorn <nwhitehorn@freebsd.org>,
 freebsd-toolchain@freebsd.org
X-Mailer: Apple Mail (2.2070.6)
Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
X-BeenThere: freebsd-ppc@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Porting FreeBSD to the PowerPC <freebsd-ppc.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-ppc>,
 <mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
 <mailto:freebsd-ppc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2015 20:12:03 -0000

Brad King is adding the missing static to _stl_next_prime in KWSys and =
from there it will eventually propagate into CMake's code base. Actually =
in KWSys both static's are to be added. (  =
http://review.source.kitware.com/#/c/19465/ )

Brad wrote that CMake's code base had added the static to =
_get_stl_prime_list to handle a linking problem in some environment. =
(Despite not knowing of KWSys I had guessed that there was some reason =
why that static was there: that is why I suggested the direction of =
making _stl_next_prime match instead of suggesting removing the static =
on _get_stl_prime_list.) Once propagated the updates will make KWSys and =
CMake's code again match in this area.

So eventually FreeBSD should pick up a fix that should allow WITH_DEBUG=3D=
 to be better behaved for CMake's programs that use it's hashtable.hxx .


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

On 2015-Mar-9, at 08:09 AM, Mark Millard <markmi at dsl-only.net> wrote:

I've discovered why/how WITH_DEBUG=3D ends up with cmake's =
/usr/local/bin/ctest messed up for PIC code generation (powerpc64 =
context). A source code fix that avoids the problem is likely to change =
cmake's hashtable.hxx that has

inline size_t _stl_next_prime(size_t __n)
{
 const unsigned long* __first =3D get_stl_prime_list();
 const unsigned long* __last =3D get_stl_prime_list() + =
(int)_stl_num_primes;
 const unsigned long* pos =3D cmsys_stl::lower_bound(__first, __last, =
__n);
 return pos =3D=3D __last ? *(__last - 1) : *pos;
}

to also indicate static for it like the .hxx file has for

static inline const unsigned long* get_stl_prime_list() {

static const unsigned long _stl_prime_list[_stl_num_primes] =3D
{
 5ul,          11ul,         23ul,
 53ul,         97ul,         193ul,       389ul,       769ul,
 1543ul,       3079ul,       6151ul,      12289ul,     24593ul,
 49157ul,      98317ul,      196613ul,    393241ul,    786433ul,
 1572869ul,    3145739ul,    6291469ul,   12582917ul,  25165843ul,
 50331653ul,   100663319ul,  201326611ul, 402653189ul, 805306457ul,
 1610612741ul, 3221225473ul, 4294967291ul
};

return &_stl_prime_list[0]; }

NOTE: _stl_next_prime has the only calls to _get_stl_prime_list that =
exist in the source code.


The details for what is going on follow...

There are 7 instances of get_stl_prime_list's code in my =
/usr/local/bin/ctest, each with differing %r2 offsets for differing %r2 =
values to allow finding appropriate _stl_prime_list addresses in various =
places that include the header file. Each code instance from my build's =
/usr/local/bin/ctest is shown below. (Note that the =
._ZN5cmsysL18get_stl_prime_listEv name does not vary despite the =
distinct addresses.)

But there is only 1 instance of _stl_next_prime's code in =
/usr/local/bin/ctest, also shown below. This routine directly calls the =
first of the ._ZN5cmsysL18get_stl_prime_listEv routines below, =
effectively forcing the %r2 offset from that code to always be used =
--and so generating garbage addresses for 6 of the 7 static contexts.

6 of the ._ZN5cmsysL18get_stl_prime_listEv's are completely unused.

But most of the initial usage of _stl_next_prime in execution order =
happens to have the %r2 value that goes with the first =
._ZN5cmsysL18get_stl_prime_listEv routine. That is why =
/usr/local/bin/ctest dies as late as it does.

I have observed the indicated behavior leading up to the crash under gdb =
as well.

00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> std     r31,-8(r1)
00000000101751c4 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu    =
r1,-64(r1)
00000000101751c8 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr      r31,r1
00000000101751cc <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld      =
r0,-2976(r2)
00000000101751d0 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr      r3,r0
00000000101751d4 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld      =
r1,0(r1)
00000000101751d8 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld      =
r31,-8(r1)
00000000101751dc <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
00000000101751e0 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
00000000101751e4 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
00000000101751e8 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz     =
r0,1(r1)

000000001017c028 <._ZN5cmsysL18get_stl_prime_listEv> std     r31,-8(r1)
000000001017c02c <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu    =
r1,-64(r1)
000000001017c030 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr      r31,r1
000000001017c034 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld      =
r0,-2720(r2)
000000001017c038 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr      r3,r0
000000001017c03c <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld      =
r1,0(r1)
000000001017c040 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld      =
r31,-8(r1)
000000001017c044 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
000000001017c048 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
000000001017c04c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
000000001017c050 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz     =
r0,1(r1)

00000000101f4ae8 <._ZN5cmsysL18get_stl_prime_listEv> std     r31,-8(r1)
00000000101f4aec <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu    =
r1,-64(r1)
00000000101f4af0 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr      r31,r1
00000000101f4af4 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld      =
r0,2088(r2)
00000000101f4af8 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr      r3,r0
00000000101f4afc <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld      =
r1,0(r1)
00000000101f4b00 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld      =
r31,-8(r1)
00000000101f4b04 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
00000000101f4b08 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
00000000101f4b0c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
00000000101f4b10 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz     =
r0,1(r1)

000000001029161c <._ZN5cmsysL18get_stl_prime_listEv> std     r31,-8(r1)
0000000010291620 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu    =
r1,-64(r1)
0000000010291624 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr      r31,r1
0000000010291628 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld      =
r0,11344(r2)
000000001029162c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr      r3,r0
0000000010291630 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld      =
r1,0(r1)
0000000010291634 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld      =
r31,-8(r1)
0000000010291638 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
000000001029163c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
0000000010291640 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
0000000010291644 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz     =
r0,1(r1)

00000000103cde60 <._ZN5cmsysL18get_stl_prime_listEv> std     r31,-8(r1)
00000000103cde64 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu    =
r1,-64(r1)
00000000103cde68 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr      r31,r1
00000000103cde6c <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld      =
r0,-32728(r2)
00000000103cde70 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr      r3,r0
00000000103cde74 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld      =
r1,0(r1)
00000000103cde78 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld      =
r31,-8(r1)
00000000103cde7c <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
00000000103cde80 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
00000000103cde84 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
00000000103cde88 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz     =
r0,1(r1)

000000001041bf4c <._ZN5cmsysL18get_stl_prime_listEv> std     r31,-8(r1)
000000001041bf50 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu    =
r1,-64(r1)
000000001041bf54 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr      r31,r1
000000001041bf58 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld      =
r0,-26608(r2)
000000001041bf5c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr      r3,r0
000000001041bf60 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld      =
r1,0(r1)
000000001041bf64 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld      =
r31,-8(r1)
000000001041bf68 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
000000001041bf6c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
000000001041bf70 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
000000001041bf74 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz     =
r0,1(r1)

00000000104719ec <._ZN5cmsysL18get_stl_prime_listEv> std     r31,-8(r1)
00000000104719f0 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu    =
r1,-64(r1)
00000000104719f4 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr      r31,r1
00000000104719f8 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld      =
r0,-21280(r2)
00000000104719fc <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr      r3,r0
0000000010471a00 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld      =
r1,0(r1)
0000000010471a04 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld      =
r31,-8(r1)
0000000010471a08 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
0000000010471a0c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
0000000010471a10 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
0000000010471a14 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz     =
r0,1(r1)

And here is the only _stl_next_prime routine:

0000000010176174 <._ZN5cmsys15_stl_next_primeEm> mflr    r0
0000000010176178 <._ZN5cmsys15_stl_next_primeEm+0x4> std     r31,-8(r1)
000000001017617c <._ZN5cmsys15_stl_next_primeEm+0x8> std     r0,16(r1)
0000000010176180 <._ZN5cmsys15_stl_next_primeEm+0xc> stdu    r1,-176(r1)
0000000010176184 <._ZN5cmsys15_stl_next_primeEm+0x10> mr      r31,r1
0000000010176188 <._ZN5cmsys15_stl_next_primeEm+0x14> std     =
r3,224(r31)
000000001017618c <._ZN5cmsys15_stl_next_primeEm+0x18> bl      =
00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv>
0000000010176190 <._ZN5cmsys15_stl_next_primeEm+0x1c> mr      r0,r3
0000000010176194 <._ZN5cmsys15_stl_next_primeEm+0x20> std     =
r0,128(r31)
0000000010176198 <._ZN5cmsys15_stl_next_primeEm+0x24> bl      =
00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv>
000000001017619c <._ZN5cmsys15_stl_next_primeEm+0x28> mr      r9,r3
00000000101761a0 <._ZN5cmsys15_stl_next_primeEm+0x2c> addi    r0,r9,248
00000000101761a4 <._ZN5cmsys15_stl_next_primeEm+0x30> std     =
r0,120(r31)
00000000101761a8 <._ZN5cmsys15_stl_next_primeEm+0x34> ld      =
r3,128(r31)
00000000101761ac <._ZN5cmsys15_stl_next_primeEm+0x38> ld      =
r4,120(r31)
00000000101761b0 <._ZN5cmsys15_stl_next_primeEm+0x3c> addi    r0,r31,224
00000000101761b4 <._ZN5cmsys15_stl_next_primeEm+0x40> mr      r5,r0
00000000101761b8 <._ZN5cmsys15_stl_next_primeEm+0x44> bl      =
0000000010176090 <._ZSt11lower_boundIPKmmET_S2_S2_RKT0_>
00000000101761bc <._ZN5cmsys15_stl_next_primeEm+0x48> crmove  =
4*cr7+so,4*cr7+so
00000000101761c0 <._ZN5cmsys15_stl_next_primeEm+0x4c> mr      r0,r3
00000000101761c4 <._ZN5cmsys15_stl_next_primeEm+0x50> std     =
r0,112(r31)
00000000101761c8 <._ZN5cmsys15_stl_next_primeEm+0x54> ld      =
r9,112(r31)
00000000101761cc <._ZN5cmsys15_stl_next_primeEm+0x58> ld      =
r0,120(r31)
00000000101761d0 <._ZN5cmsys15_stl_next_primeEm+0x5c> cmpd    cr7,r9,r0
00000000101761d4 <._ZN5cmsys15_stl_next_primeEm+0x60> bne-    =
cr7,00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78>
00000000101761d8 <._ZN5cmsys15_stl_next_primeEm+0x64> ld      =
r9,120(r31)
00000000101761dc <._ZN5cmsys15_stl_next_primeEm+0x68> addi    r9,r9,-8
00000000101761e0 <._ZN5cmsys15_stl_next_primeEm+0x6c> ld      r9,0(r9)
00000000101761e4 <._ZN5cmsys15_stl_next_primeEm+0x70> std     =
r9,144(r31)
00000000101761e8 <._ZN5cmsys15_stl_next_primeEm+0x74> b       =
00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84>
00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> ld      =
r9,112(r31)
00000000101761f0 <._ZN5cmsys15_stl_next_primeEm+0x7c> ld      r9,0(r9)
00000000101761f4 <._ZN5cmsys15_stl_next_primeEm+0x80> std     =
r9,144(r31)
00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> ld      =
r0,144(r31)
00000000101761fc <._ZN5cmsys15_stl_next_primeEm+0x88> mr      r3,r0
0000000010176200 <._ZN5cmsys15_stl_next_primeEm+0x8c> ld      r1,0(r1)
0000000010176204 <._ZN5cmsys15_stl_next_primeEm+0x90> ld      r0,16(r1)
0000000010176208 <._ZN5cmsys15_stl_next_primeEm+0x94> mtlr    r0
000000001017620c <._ZN5cmsys15_stl_next_primeEm+0x98> ld      r31,-8(r1)
0000000010176210 <._ZN5cmsys15_stl_next_primeEm+0x9c> blr
0000000010176214 <._ZN5cmsys15_stl_next_primeEm+0xa0> .long 0x0
0000000010176218 <._ZN5cmsys15_stl_next_primeEm+0xa4> .long 0x90001
000000001017621c <._ZN5cmsys15_stl_next_primeEm+0xa8> lwz     r0,1(r1)





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

On 2015-Mar-8, at 06:35 PM, Mark Millard <markmi at dsl-only.net> wrote:

Thanks for the note. It is useful to know the variation from my context.

You were not explicit but because you mention POWER8 I'd guess that you =
were reporting based on 11.0-CURRENT. I have not yet established an =
11.0-CURRENT boot-context, although I plan to at some point.


powerpc64 vs. powerpc builds give different results...

For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and =
/var/db/pkg/..., and start a rebuild of all my ports to see what =
happens. For powerpc I'm just establishing a boot-SSD context now.


The activity for both has gotten past cmake and I get the following =
results for ctest on the G5s where the builds are running:

powerpc64 build: ctest still messed up with std::length_error from =
vector::reserve.

powerpc build: ctest works fine.

Both are being run on PowerMac G5s. Both are still building more ports.



As for potential HW problems and HW configuration problems:

I have access to 3 PowerMac G5's and they all behaved the same for each =
specific build:

PowerMac11,2 (Quad-Core)     G5 with 16GBytes ECC RAM
PowerMac11,2 (Quad-Core)     G5 with 12GBytes RAM
PowerMac7,2 (Dual-processor) G5 with  8GBytes RAM

All of these have only one board installed: the video board. Normally =
there is only one "disk" present when in use: a boot SSD on ada0.

The only common HW element in my testing G5 behavior is my moving my =
boot SSD that I'm testing.

Non-SSD hardware is rarely the issue with anything that I report unless =
I'm reporting differences in behavior between the PowerMacs that I have =
access to for the type of build involved: I have a compare/contrast =
environment available for my testing and I use it.

[I have access to multiple G4 PowerMacs of various vintages and a G3 =
PowerMac as well, similarly minimal configurations. But I'm only now =
re-establishing having a FreeBSD context for these after mostly =
abandoning them for much of the 9-10 months while I was investigating =
the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD =
activity.]



The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE =
and 10.1-RELENG could certainly be suspect in some way. :) I mostly use =
10.1-STABLE, currently:

$ freebsd-version -ku; uname -a
10.1-STABLE
10.1-STABLE
FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar  6 =
23:08:59 PST 2015     root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc  =
powerpc



As for other configuration points:

See my original note for more details on the difference from the =
official world/kernel materials. There is also /boot/loader.conf picking =
out a kernel (I use INSTKERNNAME=3D with non-default names mostly) and =
picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_<?> =
for ethernet, ntpd_<?>, dumpdev, hald_enable, dbus_enable), =
/etc/sysctl.conf for /var/crash/ related items. Counting the original =
note's list of differences: Not much else is different from the =
default/official materials.

For ports configurations: Before I had suspended trying to track the =
ports status I historically had used almost every default selection, =
something like 2 to 6 non-default selections. (I keep a snapshot of =
/var/db/ports/... as a reference/reminder.) I've got the same policy for =
trying to re-establish the ports now that I can reliably boot the G5s.



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

On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn <nwhitehorn at freebsd.org> =
wrote:

This works fine for me. Are you sure you don't have some weird =
configuration or hardware problem?
-Nathan

On 03/07/15 22:56, Mark Millard wrote:
> powerpc64 context (more details are listed much later):
>=20
> $ freebsd-version -ku; uname -a
> 10.1-STABLE
> 10.1-STABLE
> FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar  =
6 23:08:59 PST 2015     root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc =
 powerpc
>=20
> Ports Revision 380683 via svnlite update. I've been using portmaster.
>=20
>=20
> The problem (which I've not figured out yet)...
>=20
> When png-1.6.16 has PNGTEST enabled (default and "recommended") it =
tries to use cmake's /usr/local/bin/ctest. But in my context ctest is =
broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s =
[see #8's ...::reserve (..., __n=3D...) below] when =
_M_initialize_buckets(..., __n=3D100) in #9. (Note: 2305843009213693952 =
=3D=3D 0x2000000000000000.) I have yet to figure out how that magic =
number is becoming involved. See below from one of the crash dumps:
>=20
> #0  0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7
> [New Thread 51c06400 (LWP 100091/ctest)]
> (gdb) bt
> #0  0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7
> #1  0x0000000050d171ac in .__raise () from /lib/libc.so.7
> #2  0x0000000050d15788 in .abort () from /lib/libc.so.7
> #3  0x00000000514c9ae0 in =
._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from =
/usr/lib/libsupc++.so.1
> #4  0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from =
/usr/lib/libsupc++.so.1
> #5  0x00000000514cf230 in ._ZSt9terminatev () from =
/usr/lib/libsupc++.so.1
> #6  0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1
> #7  0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from =
/usr/lib/libstdc++.so.6
> #8  0x000000001024659c in =
std::vector<cmsys::_Hashtable_node<std::pair<std::string const, =
cmDefinitions::Def> >*, =
std::allocator<cmsys::_Hashtable_node<std::pair<std::string const, =
cmDefinitions::Def> >*> >::reserve (this=3D0xffffffffffffb108, =
__n=3D2305843009213693952) at vector.tcc:72
> #9  0x00000000104749bc in cmsys::hashtable<std::pair<std::string =
const, cmDefinitions::Def>, std::string, cmsys::hash<std::string>, =
cmsys::hash_select1st<std::string const, cmDefinitions::Def>, =
std::equal_to<std::string>, std::allocator<char> =
>::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at =
hashtable.hxx:797
> #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, =
__n=3D100, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, =
__a=3D@0xffffffffffffaeb0) at hashtable.hxx:545
> #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at =
hash_map.hxx:113
> #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, =
parent=3D0x0) at =
/usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit=
ions.cxx:19
> #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at =
/usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil=
e.cxx:56
> #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator =
(this=3D0x51c3f480, gg=3D0xffffffffffffc138) at =
/usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe=
nerator.cxx:244
> #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator =
(this=3D0xffffffffffffc138) at =
/usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG=
enerator.cxx:1906
> #16 0x00000000100224dc in cmCTest::Initialize =
(this=3D0xffffffffffffcf50, binary_dir=3D0x51c890f8 =
"/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", =
command=3D0x0)
>   at =
/usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c=
xx:511
> #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, =
args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at =
/usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c=
xx:2474
> #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at =
/usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx=
:189
> #19 0x000000001000fc9c in ._start ()
> #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1
>=20
> The specific Makefile code to invoke ctest is...
>=20
> # Special rule for the target test
> test:
>       @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) --cyan =
"Running tests..."
>       /usr/local/bin/ctest --force-new-ctest-process $(ARGS)
> .PHONY : test
>       # Special rule for the target test
> test/fast: test
> .PHONY : test/fast
>=20
> which because of ctest's problem leads to...
>=20
> ...
> Linking C executable pngvalid
> [100%] Built target pngvalid
> (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! =
/usr/bin/env =
XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work  =
XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work  =
HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" =
XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work  =
XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work  =
HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" =
DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES =
PREFIX=3D/usr/local  LOCALBASE=3D/usr/local  LIBDIR=3D"/usr/lib"  =
CC=3D"cc" CFLAGS=3D"-pipe  -g -fno-strict-aliasing"  CPP=3D"cpp" =
CPPFLAGS=3D""  LDFLAGS=3D"" LIBS=3D""  CXX=3D"c++" CXXFLAGS=3D"-pipe -g =
-fno-strict-aliasing "  MANPREFIX=3D"/usr/local" =
BSD_INSTALL_PROGRAM=3D"install   -o root -g wheel -m 555"  =
BSD_INSTALL_LIB=3D"install   -o root -g wheel -m 444"  =
BSD_INSTALL_SCRIPT=3D"install  -o root -g wheel -m 555"  =
BSD_INSTALL_DATA=3D"install  -o root -g wheel -m 0644"  =
BSD_INSTALL_MAN=3D"instal!
> l  -o roo
> t -g wheel -m 444" /usr/bin/make -f Makefile -j4 =
DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; =
then  if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before =
reporting the failure to the maintainer. ] ; then  echo "=3D=3D=3D> =
Compilation failed unexpectedly.";  (echo Try to set =
MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the =
maintainer.) | /usr/bin/fmt 75 79 ;  fi;  false;  fi)
> Running tests...
> terminate called after throwing an instance of 'std::length_error'
> what():  vector::reserve
> Abort trap (core dumped)
> *** [test] Error code 134
>=20
> make[2]: stopped in =
/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16
> 1 error
>=20
> make[2]: stopped in =
/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16
> [: xTry: unexpected operator
> *** Error code 1
>=20
> Stop.
> make[1]: stopped in /usr/ports/graphics/png
> *** Error code 1
>=20
> Stop.
> make: stopped in /usr/ports/graphics/png
>=20
>=20
> Even just ctest as a command gets the vector::reserve size problem =
from the large magic number:
>=20
> $ ctest
> *********************************
> No test configuration file found!
> *********************************
> terminate called after throwing an instance of 'std::length_error'
> what():  vector::reserve
> Abort trap (core dumped)
>=20
>=20
> [So far I've only sidestepped having graphic/png run ctest to allow =
some things that depend on graphics/png to not be blocked by this.]
>=20
>=20
>=20
>=20
> For my context the overall environment has (but ports might force =
other ports as alternatives to):
>=20
> # more /etc/make.conf
> #CPP=3Dclang-cpp
> #CC=3Dclang
> #CXX=3Dclang++
> WRKDIRPREFIX=3D/usr/obj/portswork
> WITH_DEBUG=3D
> MALLOC_PRODUCTION=3D
>=20
> # more /etc/src.conf
> #CPP=3Dclang-cpp
> #CC=3Dclang
> #CXX=3Dclang++
> #CFLAGS+=3D-DELF_VERBOSE
> #WITH_DEBUG_FILES=3D
> #WITHOUT_CLANG=3D
>=20
> # which cc
> /usr/bin/cc
>=20
> # cc --version
> cc (GCC) 4.2.1 20070831 patched [FreeBSD]
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There =
is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR =
PURPOSE.
>=20
> # which clang
> /usr/bin/clang
>=20
> # clang --version
> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) =
20140512
> Target: powerpc64-unknown-freebsd10.1
> Thread model: posix
>=20
>=20
>=20
>=20
>=20
> Other context details:
>=20
> $ cd /usr/ports
> $ svnlite info
> Path: .
> Working Copy Root Path: /usr/ports
> URL: https://svn0.us-west.freebsd.org/ports/head
> Relative URL: ^/head
> Repository Root: https://svn0.us-west.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 380683
> Node Kind: directory
> Schedule: normal
> Last Changed Author: demon
> Last Changed Rev: 380683
> Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015)
>=20
> $ svnlite st --no-ignore
> ?       .snap
> I       distfiles
> M       graphics/libGL/bsd.mesalib.mk
> I       packages
> ?       restoresymtable
>=20
> $ svnlite diff graphics/libGL/bsd.mesalib.mk
> Index: graphics/libGL/bsd.mesalib.mk
> =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
> --- graphics/libGL/bsd.mesalib.mk	(revision 380683)
> +++ graphics/libGL/bsd.mesalib.mk	(working copy)
> @@ -136,6 +136,10 @@
> CONFIGURE_ARGS+=3D--enable-vdpau
> .endif
>=20
> +.if ${ARCH} =3D=3D powerpc64
> +CFLAGS+=3D	-mminimal-toc
> +.endif
> +
> post-patch:
> 	@${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e =
's|x86_64|amd64|' \
> 		${WRKSRC}/configure
>=20
> $ cd /usr/src
> $ svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: https://svn0.us-west.freebsd.org/base/stable/10
> Relative URL: ^/stable/10
> Repository Root: https://svn0.us-west.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 279507
> Node Kind: directory
> Schedule: normal
> Last Changed Author: ngie
> Last Changed Rev: 279507
> Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015)
>=20
> $ svnlite st --no-ignore
> ?       .snap
> ?       restoresymtable
> M       sys/ddb/db_main.c
> M       sys/ddb/db_script.c
> I       sys/powerpc/conf/GENERIC64vtsc
> I       sys/powerpc/conf/GENERICvtsc
> M       sys/powerpc/ofw/ofw_machdep.c
> M       sys/powerpc/ofw/ofwcall64.S
> M       sys/powerpc/powerpc/dump_machdep.c
>=20
> sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to =
avoid intermittent boot problems.
>=20
> sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get =
evidence if I do end up with another early-boot failure. DDB and GDB are =
listed in sys/powerpc/conf/GENERIC64vtsc for the same reason.
>=20
> sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer =
size for dumps to be small enough not to be rejected as too large of a =
DMA request size.
>=20
> sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both =
vt and sc. It includes the standard GENERIC64.
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> _______________________________________________
> freebsd-ppc@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
>=20