Date: Mon, 9 Mar 2015 08:09:07 -0700 From: Mark Millard <markmi@dsl-only.net> To: Nathan Whitehorn <nwhitehorn@freebsd.org>, freebsd-toolchain@freebsd.org Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it Message-ID: <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net> In-Reply-To: <E3BADD6E-89CD-415E-8ECE-753568C71A30@dsl-only.net> References: <A57B3364-B573-45A1-8970-D0E69DE0671A@dsl-only.net> <54FC7D92.3010405@freebsd.org> <E3BADD6E-89CD-415E-8ECE-753568C71A30@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?021318C0-0D3C-4950-AFB5-9B15E3BD3376>