powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc: -pg compile gets ../libcxxrt/terminate.cc:36:7: internal compiler error: Segmentation fault

Fri Mar 20 21:17:37 UTC 2015

It turns out that I had to rebuild powerpc64-gcc after booting into the powerpc64-gcc based installed world (and kernel). The below notes start from before that rebuild of powerpc64-gcc.

Basic context (more detail later):

> # dmesg | head
> ...
> FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015
>     root at FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc
> gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64) 
> ...

(So this is was bootstrapped via a buildworld buildkernel with CROSS_TOOLSCHAIN=powerpc64-gcc involved.)

> # freebsd-version -ku; uname -apKU
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015     root at FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG  powerpc powerpc64 1100062 1100062

WITHOUT_BOOT= and WITHOUT=LIB32= were used for the above build.
Also WITHOUT_GCC_BOOTSTRAP= WITHOUT_GCC= .
And WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= WITHOUT_LLDB= .

> # more /etc/src.conf
> CC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
> CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++
> CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp
> CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/
> X_COMPILER_TYPE=gcc
> WITH_LIBCPLUSPLUS=
> # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=powerpc64-gcc use...
> CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 -std=gnu+=11 -L/usr/obj/usr/srcC/lib/libc++
> NO_WERROR=

The active build with the compiler crash was working on:

> make -j 8 CROSS_TOOLCHAIN=powerpc64-gcc \
> WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= \
> WITHOUT_LLDB= \
> WITH_GCC_BOOTSTRAP= WITH_GCC= WITHOUT_GNUCXX= \
> WITHOUT_BOOT= WITHOUT_LIB32= \
> buildworld buildkernel \
> KERNCONF=GENERIC64vtsc-NODEBUG \
> TARGET=powerpc TARGET_ARCH=powerpc64

in the above context. But it turns out that I can show the problem in a much quicker form then waiting for the rebuild to get to that point.

The problem:

For the quicker form of test: having done buildworld buildkernel from the gcc 4.2.1 based powerpc64 SSD but using powerpc64-gcc via CROSS_TOOLCHAIN=powerpc64-gcc (much like the above)...

installworld (and installkernel) to another SSD that is effectively initially a copy of the gcc 4.2.1 based one with the powerpc64-gcc present. Then reboot into that newer SSD. Using the above /etc/src.conf then try something like:

> mkdir -p /tmp/lib \
> && mkdir -p /tmp/usr/lib \
> && mkdir -p /tmp/usr/srcC/lib/libcxxrt \
> && cd /usr/srcC/lib/libcxxrt/  \
> && MAKEOBJDIRPREFIX=/tmp  \
>    make CROSS_TOOLCHAIN=powerpc64-gcc DIRPRFX=lib/libcxxrt/ DESTDIR=/tmp obj depend all install

The point being to get the involved .cc files to be compiled in the normal way, including in the form that uses -pg.

This which works fine on the original SSD (given that SSD's /etc/src.conf that uses CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 and LDADD+=-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ ).

The result for -pg for contrib/libcxxrt/terminate.cc on the gcc 4.9.1 based SSD was consistently:

> /usr/srcC/lib/libcxxrt/../../contrib/libcxxrt/terminate.cc: In function 'void std::terminate()':
> /usr/srcC/lib/libcxxrt/../../contrib/libcxxrt/terminate.cc:36:7: internal compiler error: Segmentation fault
>   void terminate()
>        ^
> no stack trace because unwind library not available
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> *** [terminate.po] Error code 1
> 
> make[4]: stopped in /usr/srcC/lib/libcxxrt
> 1 error
> 
> make[4]: stopped in /usr/srcC/lib/libcxxrt
> *** [all_subdir_libcxxrt] Error code 2

Rebuilding powerpc64-gcc from the booted powerpc64-gcc based SSD (in my case via gcc5 use and portmaster) and trying again shows that the rebuild has removed the above crash status for -pg use.

(Until the powerpc64-gcc port avoids failing for file name/placement problems when used on powerpc64's, having powerpc64-gcc rebuild itself in such a context is a no-go: It fails between removing itself and putting back the newer materials. That does not leave enough materials around for a portmaster with -C to continue after a hand adjusted group of file names/placements.)

There appears to be some form of binary incompatibility for -pg that requires the powerpc64-gcc rebuild to get the new binary context right. Once it matches it seems fine.

Context details, mostly applying to both gcc 4.2.1 based world/kernel with powperpc-gcc in use for cross compiling and gcc 4.9.1 based world/kernel:

powerpc64-gcc automatically looks in /usr/local/include for header files (like most such ports) and this can pick up the wrong file(s). I ended up renaming

/usr/local/include/iconv.h

so that it would not be found and used where a file with different content from my /usr/srcC/... was needed.

In my experiments at times for the 4.9.1 based live-world I've placed the following symbolic links:

> # ls -FPal /usr/lib/libstdc*
> lrwxr-xr-x  1 root  wheel  8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> libc++.a
> lrwxr-xr-x  1 root  wheel  9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> libc++.so
> 
> # ls -FPal /usr/bin/gcc /usr/bin/g++
> lrwxr-xr-x  1 root  wheel  48 Mar 19 04:20 /usr/bin/g++@ -> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++
> lrwxr-xr-x  1 root  wheel  48 Mar 19 04:20 /usr/bin/gcc@ -> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc

For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC.

The CC, CXX, and CPP in...

> # more /etc/src.conf
> CC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
> CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++
> CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp
> ...

that essentially duplicate the XCC, XCXX, XCPP assignments from CROSS_TOOLCHAIN=powerpc64-gcc are there because otherwise various stages do not use the cross tools (legacy, bootstrap-tools, build-tools, cross-tools, kernel-tools, lib32's build-tools).

In the running world built-via-powerpc64-gcc environment /etc/src.conf having ...

> # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=powerpc64-gcc use...
> CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 -std=gnu+=11 -L/usr/obj/usr/srcC/lib/libc++

is used because otherwise (for example)...

> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC  -O2 -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H -fstack-protector -Wsyste
> m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized   -c /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So

ends up with...

> In file included from /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0:
> /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal error: ostream: No such file or directory
>  #include <ostream>
>                    ^
> compilation terminated.

from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 in CXXFLAGS and the like. This is despite the /usr/srcC/Makefile.inc1 logic (that ends up inactive for some reason):

> .if ${XCC:M/*}
> ...
> .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc
> XCFLAGS+=       -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib
> XCXXFLAGS+=     -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11 -L${WORLDTMP}/../lib/libc++
> DEPFLAGS+=      -I${WORLDTMP}/usr/include/c++/v1

As for /etc/make.conf it looks like...

> # more /etc/make.conf
> #CC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
> #CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++
> #CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp
> #CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/
> #X_COMPILER_TYPE=gcc
> # CXFLAGS For normal powerpc64-gcc use...
> # AVOID during buildworld/buildkernel activity.
> # See /etc/src.conf for example buildworld/buildkernel values.
> #CXXFLAGS+=-I/usr/include/c++/v1 -std=gnu++11  -L/usr/obj/usr/srcC/lib/libc++
> #
> #CC=/usr/local/bin/gcc5
> #CXX=/usr/local/bin/g++5
> #CPP=/usr/local/bin/cpp5
> #CC=/usr/local/bin/clang36
> #CXX=/usr/local/bin/clang++36
> #CPP=/usr/local/bin/clang-cpp36
> WRKDIRPREFIX=/usr/obj/portswork
> #WITH_DEBUG=
> MALLOC_PRODUCTION=

(Some of the comments show how gcc5/g++5 use was temporarily forced while rebuilding powerpc64-gcc.)

> # svnlite info /usr/srcC/
> Path: /usr/srcC
> Working Copy Root Path: /usr/srcC
> URL: https://svn0.us-west.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: https://svn0.us-west.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 279514
> Node Kind: directory
> Schedule: normal
> Last Changed Author: adrian
> Last Changed Rev: 279514
> Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015)

> # svnlite status /usr/srcC/ --no-ignore
> ?       /usr/srcC/.snap
> M       /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h
> ?       /usr/srcC/restoresymtable
> M       /usr/srcC/sys/ddb/db_main.c
> M       /usr/srcC/sys/ddb/db_script.c
> ?       /usr/srcC/sys/powerpc/conf/GENERIC64vtsc
> ?       /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG
> ?       /usr/srcC/sys/powerpc/conf/GENERICvtsc
> ?       /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG
> M       /usr/srcC/sys/powerpc/ofw/ofw_machdep.c
> M       /usr/srcC/sys/powerpc/ofw/ofwcall64.S

IntrusiveRefCntPtr.h does not matter if clang building is not involved. It needed a friend declaration to gain access to a private field, otherwise compilation stopped.

And the rest existed in my environment before I started this powerpc64-xtoolchain-gcc exploration.

lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from later (-r279760) than the rest of the unmodified source code. This is in order to remove ambiguous overload issues.

> # svnlite info /usr/ports
> Path: /usr/ports
> 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: 381120
> Node Kind: directory
> Schedule: normal
> Last Changed Author: dbn
> Last Changed Rev: 381120
> Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015)

I have gcc5 and clang36 ports installed. I made no use of clang36.

On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete its installation because powerpc64-gcc fails to complete its installation. The problems were 4 mismatched file names and one file also not put into staging. I copied appropriate files to the missing names and place and from that status the installation was able to continue and complete via postmaster with -C (as long as powerpc64-gcc was not in use rebuilding itself: some other compiler was in use for that activity instead).

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