From owner-freebsd-toolchain@freebsd.org Sun Dec 4 01:15:48 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33E2EC57209
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sun, 4 Dec 2016 01:15:48 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 08F262EA
for <freebsd-toolchain@FreeBSD.org>; Sun, 4 Dec 2016 01:15:48 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB41Fl5u015615
for <freebsd-toolchain@FreeBSD.org>; Sun, 4 Dec 2016 01:15:47 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0:
llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops
Date: Sun, 04 Dec 2016 01:15:48 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: markmi@dsl-only.net
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-214902-29464-mmJohcPS8W@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-214902-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-214902-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Dec 2016 01:15:48 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902
--- Comment #5 from Mark Millard <markmi@dsl-only.net> ---
(In reply to Mark Millard from comment #3)
I showed the wrong SRC_ENV_CONF file. It should have
been (using the system compiler):
# more ~/src.configs/src.conf.powerpc64-clang_altbinutils.powerpc64-host
TO_TYPE=3Dpowerpc64
TOOLS_TO_TYPE=3D${TO_TYPE}
VERSION_CONTEXT=3D12.0
#
KERNCONF=3DGENERIC64vtsc-NODBG
TARGET=3Dpowerpc
.if ${.MAKE.LEVEL} =3D=3D 0
TARGET_ARCH=3D${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=3D
WITH_SYSTEM_COMPILER=3D
#
WITH_LIBCPLUSPLUS=3D
WITHOUT_BINUTILS_BOOTSTRAP=3D
WITH_CLANG_BOOTSTRAP=3D
WITH_CLANG=3D
WITH_CLANG_IS_CC=3D
WITH_CLANG_FULL=3D
WITH_CLANG_EXTRAS=3D
WITH_LLDB=3D
#
WITH_BOOT=3D
# world32/usr/src/lib/csu/powerpc/crti.o got:
# csu/powerpc/crti.S:34:13: error: unexpected token in memory operand
# csu/powerpc/crti.S:35:2: error: invalid instruction mnemonic 'mflr'
# and the like. So avoid LIB32.
WITHOUT_LIB32=3D
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D
WITHOUT_GCC_BOOTSTRAP=3D
WITHOUT_GCC=3D
WITHOUT_GCC_IS_CC=3D
WITHOUT_GNUCXX=3D
#
NO_WERROR=3D
#WERROR=3D
MALLOC_PRODUCTION=3D
#
WITH_DEBUG_FILES=3D
#
CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} =3D=3D 0
CC=3D/usr/bin/clang -B ${CROSS_BINUTILS_PREFIX}
CXX=3D/usr/bin/clang++ -B ${CROSS_BINUTILS_PREFIX}
CPP=3D/usr/bin/clang-cpp -B ${CROSS_BINUTILS_PREFIX}
.export CC
.export CXX
.export CPP
AS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
AR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
LD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
NM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
OBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
OBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
RANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: STRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
STRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export AS
.export AR
.export LD
.export NM
.export OBJCOPY
.export OBJDUMP
.export RANLIB
.export SIZE
.export STRINGS
.endif
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sun Dec 4 02:54:11 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32431C66266
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sun, 4 Dec 2016 02:54:11 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net
[208.70.210.4])
(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 DA63B1C90
for <freebsd-toolchain@freebsd.org>; Sun, 4 Dec 2016 02:54:10 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 9703 invoked from network); 4 Dec 2016 02:54:10 -0000
Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1)
by 0 (rfx-qmail) with SMTP; 4 Dec 2016 02:54:10 -0000
Received: by mail-cs-01.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Sat, 03 Dec 2016 21:54:14 -0500 (EST)
Received: (qmail 14088 invoked from network); 4 Dec 2016 02:54:14 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Dec 2016 02:54:14 -0000
Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net
[76.115.7.162])
by iron2.pdx.net (Postfix) with ESMTPSA id DD783EC8AF4;
Sat, 3 Dec 2016 18:54:02 -0800 (PST)
From: Mark Millard <markmi@dsl-only.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: head -r309179 powerpc64 WITH_LIB32= buildworld only works on
powerpc64, not on cross build from amd64
Message-Id: <DFC84CD9-9896-42F2-B1FD-DA936C283F97@dsl-only.net>
Date: Sat, 3 Dec 2016 18:54:02 -0800
Cc: Justin Hibbits <chmeeedalf@gmail.com>,
Kevin Bowling <kevin.bowling@kev009.com>,
Roman Divacky <rdivacky@freebsd.org>
To: Dimitry Andric <dim@freebsd.org>,
FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Dec 2016 02:54:11 -0000
I just discovered that, even though I could not build WITH_LIB32=3D
for TARGET_ARCH=3Dpowerpc64 from amd64, after booting the cross
built system I was able to buildworld using WITH_LIB32=3D
based on the SRC_ENV_CONF that I list later. Installing,
booting, and testing it works:
# ldd32 /usr/lib32/libgcc_s.so.1=20
/usr/lib32/libgcc_s.so.1:
libc.so.7 =3D> /usr/lib32/libc.so.7 (0x41841000)
# file `which ldd32`
/usr/bin/ldd32: ELF 32-bit MSB executable, PowerPC or cisco 4500, =
version 1 (FreeBSD), dynamically linked, interpreter =
/libexec/ld-elf.so.1, for FreeBSD 12.0 (1200017), FreeBSD-style, =
stripped
The blocking issue on amd64's cross build was rejection of
assembler notation used in lib32's build. Turns out from the
message text details that the compiler was in either the ATT
or the Intel instruction set parsing code when it rejected
the notation.
I have submitted a bugzilla report for this:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215037
Supporting details for the on powerpc64 build:
-r416639 devel/binutils
-r407342 devel/powerpc-binutils
(slave port so tracks devel/binutils in various ways)
(The above avoids 2.47 vintages.)
# head =
~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils_=
world-powerpc64-host-2016-12-03:17:42:59=20
Script started on Sat Dec 3 17:42:59 2016
Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/null=
=
SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc64-clang_altbinutils.powe=
rpc64-host WITH_META_MODE=3Dyes =
MAKEOBJDIRPREFIX=3D/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.=
powerpc64 make -j 5 buildworld
. . .
# more =
/root/src.configs/src.conf.powerpc64-clang_altbinutils.powerpc64-host
TO_TYPE=3Dpowerpc64
TOOLS_TO_TYPE=3D${TO_TYPE}
VERSION_CONTEXT=3D12.0
#
KERNCONF=3DGENERIC64vtsc-NODBG
TARGET=3Dpowerpc
.if ${.MAKE.LEVEL} =3D=3D 0
TARGET_ARCH=3D${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=3D
WITH_SYSTEM_COMPILER=3D
#
WITH_LIBCPLUSPLUS=3D
WITHOUT_BINUTILS_BOOTSTRAP=3D
WITH_CLANG_BOOTSTRAP=3D
WITH_CLANG=3D
WITH_CLANG_IS_CC=3D
WITH_CLANG_FULL=3D
WITH_CLANG_EXTRAS=3D
WITH_LLDB=3D
#
WITH_BOOT=3D
WITH_LIB32=3D
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D
WITHOUT_GCC_BOOTSTRAP=3D
WITHOUT_GCC=3D
WITHOUT_GCC_IS_CC=3D
WITHOUT_GNUCXX=3D
#
NO_WERROR=3D
#WERROR=3D
MALLOC_PRODUCTION=3D
#
WITH_DEBUG_FILES=3D
#
CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} =3D=3D 0
CC=3D/usr/bin/clang -B ${CROSS_BINUTILS_PREFIX}
CXX=3D/usr/bin/clang++ -B ${CROSS_BINUTILS_PREFIX}
CPP=3D/usr/bin/clang-cpp -B ${CROSS_BINUTILS_PREFIX}
.export CC
.export CXX
.export CPP
AS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
AR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
LD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
NM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
OBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
OBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
RANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: STRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
STRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export AS
.export AR
.export LD
.export NM
.export OBJCOPY
.export OBJDUMP
.export RANLIB
.export SIZE
.export STRINGS
.endif
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
From owner-freebsd-toolchain@freebsd.org Sun Dec 4 04:36:00 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F54AC666C1
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sun, 4 Dec 2016 04:36:00 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net
[208.70.210.5])
(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 B857D171B
for <freebsd-toolchain@freebsd.org>; Sun, 4 Dec 2016 04:35:58 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 21991 invoked from network); 4 Dec 2016 04:36:39 -0000
Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2)
by 0 (rfx-qmail) with SMTP; 4 Dec 2016 04:36:39 -0000
Received: by mail-cs-02.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Sat, 03 Dec 2016 23:35:59 -0500 (EST)
Received: (qmail 13855 invoked from network); 4 Dec 2016 04:35:59 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Dec 2016 04:35:59 -0000
Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net
[76.115.7.162])
by iron2.pdx.net (Postfix) with ESMTPSA id 3703BEC9143;
Sat, 3 Dec 2016 20:35:51 -0800 (PST)
From: Mark Millard <markmi@dsl-only.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
Message-Id: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
Date: Sat, 3 Dec 2016 20:35:50 -0800
Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
FreeBSD Toolchain <freebsd-toolchain@freebsd.org>
To: Justin Hibbits <chmeeedalf@gmail.com>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Dec 2016 04:36:00 -0000
[Note: At present I can buildworld using WITH_LIB32=3D on
powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a
minor variant of head -r309179 . That does not work for
amd64 cross compiling to powerpc64 due to assembler
notation rejections.]
When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's
clang 3.9.0 I get the following sorts of error
reports, *even building on powerpc64* :
--- hwpmc_e500.o ---
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
__asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
^
<inline asm>:1:2: note: instantiated into assembly here
mfpmr 3,400
^
. . .
When I look up these instructions I find that they are not
classic powerpc instructions:
( =
http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd=
f )
> Whereas the classic architecture defines special-purpose registers =
(SPRs) and
> two instructions to access them (Move to Special-Purpose Register =
(mtspr) and
> Move from Special-Purpose Register (mfspr)), Book E takes that model =
and defines
> optional device control registers (DCRs) and mtdcr and mfdcr =
instructions, and
> the EIS-defined performance monitor APU defines performance monitor =
registers
> (PMRs) and mtpmr and mfpmr instructions, all based on models provided =
by the
> UISA.
. . .
Does this imply that clang 3.9.0 needs to support more instructions when
it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC64
and then override some items for my build activity.)
If yes, then someone probably needs to make a list of what instructions
need to be present and have someone submit the list into llvm's bugzilla
and have the submittal listed in:
[META] Using Clang as the FreeBSD/ppc system compiler
(25780).
If GENERIC64 does not need the likes of hwpmc_e500.o built then some
work on the build environment to avoid GENERIC64 including things with
non-classic instruction use would appear to be needed. (No llvm
involvement for this case.) I doubt this is the case as it would
seem that the problem would reoccur when alternate KERNCONF's were
in use instead that do require something like of hwpmc_e500.o to be
built.
Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is =
about
this issue from the FreeBSD side of things. I just noticed the status
of the specific instructions involved and also that the cross-build
and on-powerpc64 build get the same result (unlike the recent
WITH_LIB32=3D discovery).
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
From owner-freebsd-toolchain@freebsd.org Sun Dec 4 05:14:43 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id C646DC662AE
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sun, 4 Dec 2016 05:14:43 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 B55B682E
for <freebsd-toolchain@FreeBSD.org>; Sun, 4 Dec 2016 05:14:43 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB45EhnU019131
for <freebsd-toolchain@FreeBSD.org>; Sun, 4 Dec 2016 05:14:43 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64
cross-built buildkernel stops for: rejected assembler notation
Date: Sun, 04 Dec 2016 05:14:44 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: markmi@dsl-only.net
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-214904-29464-VV89y04mxW@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-214904-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-214904-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Dec 2016 05:14:43 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904
--- Comment #1 from Mark Millard <markmi@dsl-only.net> ---
(In reply to Mark Millard from comment #0)
I've now also tried this on a powerpc64 running a minor variant
of head -r309179 and it gets the same result that the amd64
cross build for TARGET_ARCH=3Dpowerpc64 does --unlike the
buildworld WITH_LIB32=3D issue now listed in bugzilla 215037.
Here it seems that the "BOOK E" specific instructions are
missing from the assembler notation that clang 3.9.0 supports
for TARGET_ARCH=3Dpowerpc64. There might be other non-classic
PowerPc instructions also missing for all I know.
I've sent a note asking Justin Hibbits what he thinks the
proper classification of this is. Does llvm need to support
the BOOK E specific instructions on the assembler notation
in order for FreeBSD to use clang as the system compiler?
Even if GENERIC64 could avoid including such things there
would still be the issue of how to allow more specialized
builds to target BOOK E (or other variants with special
instructions for the variant).
This may need a related llvm bugzilla submittal to be
listed in the:
[META] Using Clang as the FreeBSD/ppc system compiler
(25780 for llvm).
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sun Dec 4 07:31:41 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA812C66EF1
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sun, 4 Dec 2016 07:31:41 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net
[208.70.210.5])
(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 8D3F81EB
for <freebsd-toolchain@freebsd.org>; Sun, 4 Dec 2016 07:31:41 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 25660 invoked from network); 4 Dec 2016 07:31:39 -0000
Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1)
by 0 (rfx-qmail) with SMTP; 4 Dec 2016 07:31:39 -0000
Received: by rtc-sm-01.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Sun, 04 Dec 2016 02:31:39 -0500 (EST)
Received: (qmail 12799 invoked from network); 4 Dec 2016 07:31:39 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Dec 2016 07:31:39 -0000
Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net
[76.115.7.162])
by iron2.pdx.net (Postfix) with ESMTPSA id DE4D0EC8AF4;
Sat, 3 Dec 2016 23:31:38 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND [
WITH_LLVM_LIBUNWIND= based buildworld fails on powerpc64 for
TARGET_ARCH=powerpc64 ]
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <CAPyFy2ArXUYsyTC9LY_CqbU3FLVV0TeV+Sandqd-SpPGMBL6Cg@mail.gmail.com>
Date: Sat, 3 Dec 2016 23:31:38 -0800
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Dimitry Andric <dim@freebsd.org>
Content-Transfer-Encoding: 7bit
Message-Id: <09B0D6F7-F2F3-4AA3-9EE6-5D51655549BE@dsl-only.net>
References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net>
<CAPyFy2ArXUYsyTC9LY_CqbU3FLVV0TeV+Sandqd-SpPGMBL6Cg@mail.gmail.com>
To: Ed Maste <emaste@freebsd.org>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Dec 2016 07:31:42 -0000
On 2016-Nov-29, at 2:56 PM, Ed Maste <emaste at freebsd.org> wrote:
> On 29 November 2016 at 16:46, Mark Millard <markmi at dsl-only.net> wrote:
>>
>>
>> Summary: Does using clang 3.9.0 as the system compiler imply one should or
>> must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work?
>>
>> Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria
>> for what dwarfdump should show for the exception information (if the
>> information to be shown is to be correct/sufficient for libunwind)?
>
> It does not. It should be possible to build a functional system both
> WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the
> _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind
> data.
>
> Eventually new features may show up in Clang and LLVM's libunwind (and
> new versions of GNU's unwinder) that won't work with the old unwinder.
>
>> Your answer's detail might indicate that I've misdirected the llvm folks
>> in submittals like https://llvm.org/bugs/show_bug.cgi?id=26844 .
>>
>> There is also the question of if/when llvm's libunwind is ready to be used
>> for powerpc64 or powerpc (or . . .) if there are architecture specifics
>> involved. That answer might determine when C++ exceptions work (and so
>> when devel/kyua might have a chance to work) and is sort of separate from
>> the main question here but is still of interest overall.
>>
>> Should powerpc64 and powerpc clang 3.9.0 testing be using
>> WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both?
>
> For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My
> eventual goal is to have a functioning Clang, LLD, LLDB, libunwind,
> and ELF Tool Chain on all of our supported architectures.
I tried adding WITH_LLVM_LIBUNWIND= to the SRC_CONF_ENV file that I
use on powerpc64 for TARGET_ARCH=powerpc64 for (a minor variation of)
head -r309179 based on clang 3.9.0. It failed to complete buildworld:
A) An assert failed in libunwind/src/UnwindCursor.hpp .
B) Two .S files got massive numbers of error messages
( libgcc_eh/UnwindRegisterRestore.S and
libgcc_eh/UnwindRegisterSave.S )
And those points stopped the build.
See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215039
Note: using WITHOUT_LLVM_LIBUNWIND= (implicit) I've done
buildworld using WITH_LIB32= just fine and rebooted with
it installed and then did more buildworld experiments. The
above started from a working environment for such things.
Unfortunately for gcc's libunwind clang's code generation
is broken (counting .eh dwarf information as code). C++
exceptions are one area that does not even do simple
things correctly for powerpc64 (or for powerpc): I have
to avoid using programs that depend on C++ exceptions
happening.
===
Mark Millard
markmi at dsl-only.net
From owner-freebsd-toolchain@freebsd.org Mon Dec 5 16:27:13 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97DB9C68503;
Mon, 5 Dec 2016 16:27:13 +0000 (UTC)
(envelope-from rdivacky@vlakno.cz)
Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224])
by mx1.freebsd.org (Postfix) with ESMTP id 29F4C106F;
Mon, 5 Dec 2016 16:27:12 +0000 (UTC)
(envelope-from rdivacky@vlakno.cz)
Received: by vlakno.cz (Postfix, from userid 1002)
id 503AEA35642; Mon, 5 Dec 2016 17:19:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail;
t=1480954745; bh=E1KmZY+c9aRqJBBWpfR4XjDFEXTf8EqaCsyi39U/SaQ=;
h=Date:From:To:Cc:Subject:References:In-Reply-To;
b=Z0jQCaVVoJaEGDuHW2+x2YD1RgM2+tCVk8DHLaJn1kVDbw7HZWsJew5isxxLC2I9/
u3bf1f0UWF1X7ScJEf9JvOdZ20bM2og3dem1Ujf/qed1n2X7Sa75w3+1g1lC9yH16P
n5vUUo9gALDtMV3Ke0lvc+AC5dl0RE93Lj0qImkw=
Date: Mon, 5 Dec 2016 17:19:05 +0100
From: Roman Divacky <rdivacky@vlakno.cz>
To: Mark Millard <markmi@dsl-only.net>
Cc: Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
Message-ID: <20161205161904.GA7889@vlakno.cz>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2016 16:27:13 -0000
Can you try this patch?
Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
===================================================================
--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
@@ -2373,6 +2373,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
On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote:
> [Note: At present I can buildworld using WITH_LIB32= on
> powerpc64 for TARGET_ARCH=powerpc64 via clang 3.9.0 from a
> minor variant of head -r309179 . That does not work for
> amd64 cross compiling to powerpc64 due to assembler
> notation rejections.]
>
> When I attempt to buildkernel (with WERROR= ) via FreeBSD's
> clang 3.9.0 I get the following sorts of error
> reports, *even building on powerpc64* :
>
> --- hwpmc_e500.o ---
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: unrecognized instruction mnemonic
> uint32_t pmgc0 = mfpmr(PMR_PMGC0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=r"(val) : "K"(reg)); \
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 3,400
> ^
> . . .
>
> When I look up these instructions I find that they are not
> classic powerpc instructions:
> ( http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pdf )
>
> > Whereas the classic architecture defines special-purpose registers (SPRs) and
> > two instructions to access them (Move to Special-Purpose Register (mtspr) and
> > Move from Special-Purpose Register (mfspr)), Book E takes that model and defines
> > optional device control registers (DCRs) and mtdcr and mfdcr instructions, and
> > the EIS-defined performance monitor APU defines performance monitor registers
> > (PMRs) and mtpmr and mfpmr instructions, all based on models provided by the
> > UISA.
>
> . . .
>
> Does this imply that clang 3.9.0 needs to support more instructions when
> it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC64
> and then override some items for my build activity.)
>
> If yes, then someone probably needs to make a list of what instructions
> need to be present and have someone submit the list into llvm's bugzilla
> and have the submittal listed in:
>
> [META] Using Clang as the FreeBSD/ppc system compiler
>
> (25780).
>
>
> If GENERIC64 does not need the likes of hwpmc_e500.o built then some
> work on the build environment to avoid GENERIC64 including things with
> non-classic instruction use would appear to be needed. (No llvm
> involvement for this case.) I doubt this is the case as it would
> seem that the problem would reoccur when alternate KERNCONF's were
> in use instead that do require something like of hwpmc_e500.o to be
> built.
>
>
> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214903 is about
> this issue from the FreeBSD side of things. I just noticed the status
> of the specific instructions involved and also that the cross-build
> and on-powerpc64 build get the same result (unlike the recent
> WITH_LIB32= discovery).
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> _______________________________________________
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org"
From owner-freebsd-toolchain@freebsd.org Tue Dec 6 00:32:01 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29F17C5933F
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Tue, 6 Dec 2016 00:32:01 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net
[208.70.210.10])
(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 E31EC18BF
for <freebsd-toolchain@freebsd.org>; Tue, 6 Dec 2016 00:32:00 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 7030 invoked from network); 6 Dec 2016 00:06:08 -0000
Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1)
by 0 (rfx-qmail) with SMTP; 6 Dec 2016 00:06:08 -0000
Received: by mail-cs-01.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Mon, 05 Dec 2016 19:05:30 -0500 (EST)
Received: (qmail 2149 invoked from network); 6 Dec 2016 00:05:30 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Dec 2016 00:05:30 -0000
Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net
[67.170.167.181])
by iron2.pdx.net (Postfix) with ESMTPSA id 947ABEC91F9;
Mon, 5 Dec 2016 16:05:18 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <20161205161904.GA7889@vlakno.cz>
Date: Mon, 5 Dec 2016 16:05:17 -0800
Cc: Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
To: Roman Divacky <rdivacky@vlakno.cz>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 00:32:01 -0000
On 2016-Dec-5, at 8:19 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
> Can you try this patch?
>=20
> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> @@ -2373,6 +2373,12 @@
> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
> "mftb $RT, $SPR", IIC_SprMFTB>;
>=20
> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
> + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
> +
> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
> + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
> +
> // A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
> // on a 32-bit target.
> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
Direct use of the patch (put into a file) was rejected:
# patch -p0 < llvmPPCInstrInfo_td.patch=20
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
|+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
--------------------------
Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A...
patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, =
(outs gprc:$RT), (ins i32imm:$SPR),
So I hand put in the extra lines.
I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124
the MFTB line is at line number 2300 while your patch listed:
@@ -2373,6 +2373,12 @@
My edit shows as:
# svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision =
309179)
+++ 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>;
=20
+def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
+ "mfpmr $RT, $PMRN", IIC_IntGeneral>;
+
+def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
+ "mtpmr $PMRN, $RS", IIC_IntGeneral>;
+
// A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
// on a 32-bit target.
let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
Unfortunately the buildkernel still gets the same errors:
(This was tried after a kernel-toolchain .)
# Meta data file =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met=
a
CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target =
powerpc64-unknown-freebsd12.0 =
--sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp=
c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe =
-fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc =
-DHAVE_KERNEL_OPTION_HEADERS -include =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g =
-fno-omit-frame-pointer =
-I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr=
c/sys/GENERIC64vtsc-NODBG -mno-altivec -ffreestanding -fwrapv =
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs =
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline =
-Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ =
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas =
-Wno-error-tautological-compare -Wno-error-empty-body =
-Wno-error-parentheses-equality -Wno-error-unused-function =
-Wno-error-pointer-sign -Wno-error-shift-negative-value -msoft-float =
-std=3Diso9899:1999 -c =
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o
CMD ctfconvert -L VERSION -g hwpmc_e500.o
CWD =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc
TARGET hwpmc_e500.o
-- command output --
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
__asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
^
<inline asm>:1:2: note: instantiated into assembly here
mfpmr 3,400
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: =
unrecognized instruction mnemonic
mtpmr(PMR_PMGC0, pmgc0);
^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
__asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
^
<inline asm>:1:2: note: instantiated into assembly here
mtpmr 400,3
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: =
unrecognized instruction mnemonic
mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE);
^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
__asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
^
<inline asm>:1:2: note: instantiated into assembly here
mtpmr 400,3
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: =
unrecognized instruction mnemonic
pmc_pmlc =3D mfpmr(PMR_PMLCa0);
^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
__asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
^
<inline asm>:1:2: note: instantiated into assembly here
mfpmr 10,144
^
. . .
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Older content:
On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote:
> [Note: At present I can buildworld using WITH_LIB32=3D on
> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a
> minor variant of head -r309179 . That does not work for
> amd64 cross compiling to powerpc64 due to assembler
> notation rejections.]
>=20
> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's
> clang 3.9.0 I get the following sorts of error
> reports, *even building on powerpc64* :
>=20
> --- hwpmc_e500.o ---
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 3,400
> ^
> . . .
>=20
> When I look up these instructions I find that they are not
> classic powerpc instructions:
> ( =
http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd=
f )
>=20
>> Whereas the classic architecture defines special-purpose registers =
(SPRs) and
>> two instructions to access them (Move to Special-Purpose Register =
(mtspr) and
>> Move from Special-Purpose Register (mfspr)), Book E takes that model =
and defines
>> optional device control registers (DCRs) and mtdcr and mfdcr =
instructions, and
>> the EIS-defined performance monitor APU defines performance monitor =
registers
>> (PMRs) and mtpmr and mfpmr instructions, all based on models provided =
by the
>> UISA.
>=20
> . . .
>=20
> Does this imply that clang 3.9.0 needs to support more instructions =
when
> it is targeting FreeBSD for GENERIC64 based builds? (I include =
GENERIC64
> and then override some items for my build activity.)
>=20
> If yes, then someone probably needs to make a list of what =
instructions
> need to be present and have someone submit the list into llvm's =
bugzilla
> and have the submittal listed in:
>=20
> [META] Using Clang as the FreeBSD/ppc system compiler
>=20
> (25780).
>=20
>=20
> If GENERIC64 does not need the likes of hwpmc_e500.o built then some
> work on the build environment to avoid GENERIC64 including things with
> non-classic instruction use would appear to be needed. (No llvm
> involvement for this case.) I doubt this is the case as it would
> seem that the problem would reoccur when alternate KERNCONF's were
> in use instead that do require something like of hwpmc_e500.o to be
> built.
>=20
>=20
> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is =
about
> this issue from the FreeBSD side of things. I just noticed the status
> of the specific instructions involved and also that the cross-build
> and on-powerpc64 build get the same result (unlike the recent
> WITH_LIB32=3D discovery).
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
From owner-freebsd-toolchain@freebsd.org Tue Dec 6 01:22:50 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B206EC66528
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Tue, 6 Dec 2016 01:22:50 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net
[208.70.210.14])
(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 770931747
for <freebsd-toolchain@freebsd.org>; Tue, 6 Dec 2016 01:22:49 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 7166 invoked from network); 6 Dec 2016 01:16:16 -0000
Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1)
by 0 (rfx-qmail) with SMTP; 6 Dec 2016 01:16:16 -0000
Received: by mail-cs-01.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Mon, 05 Dec 2016 20:16:20 -0500 (EST)
Received: (qmail 6195 invoked from network); 6 Dec 2016 01:16:20 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Dec 2016 01:16:20 -0000
Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net
[67.170.167.181])
by iron2.pdx.net (Postfix) with ESMTPSA id 39960EC7977;
Mon, 5 Dec 2016 17:16:08 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
Date: Mon, 5 Dec 2016 17:16:07 -0800
Cc: Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
To: Roman Divacky <rdivacky@vlakno.cz>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 01:22:50 -0000
[Top post of a retry using a different SRC_CONF_ENV file.]
Well it looks like:
WITHOUT_CROSS_COMPILER=3D
WITH_SYSTEM_COMPILER=3D
ignores the .td file change but
WITH_CROSS_COMPILER=3D
WITHOUT_SYSTEM_COMPILER=3D
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. . .
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Dec-5, at 4:05 PM, Mark Millard <markmi at dsl-only.net> wrote:
On 2016-Dec-5, at 8:19 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
> Can you try this patch?
>=20
> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> @@ -2373,6 +2373,12 @@
> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
> "mftb $RT, $SPR", IIC_SprMFTB>;
>=20
> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
> + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
> +
> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
> + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
> +
> // A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
> // on a 32-bit target.
> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
Direct use of the patch (put into a file) was rejected:
# patch -p0 < llvmPPCInstrInfo_td.patch=20
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
|+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
--------------------------
Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A...
patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, =
(outs gprc:$RT), (ins i32imm:$SPR),
So I hand put in the extra lines.
I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124
the MFTB line is at line number 2300 while your patch listed:
@@ -2373,6 +2373,12 @@
My edit shows as:
# svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision =
309179)
+++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
@@ -2300,6 +2300,12 @@
def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
"mftb $RT, $SPR", IIC_SprMFTB>;
+def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
+ "mfpmr $RT, $PMRN", IIC_IntGeneral>;
+
+def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
+ "mtpmr $PMRN, $RS", IIC_IntGeneral>;
+
// A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
// on a 32-bit target.
let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
Unfortunately the buildkernel still gets the same errors:
(This was tried after a kernel-toolchain .)
# Meta data file =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met=
a
CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target =
powerpc64-unknown-freebsd12.0 =
--sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp=
c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe =
-fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc =
-DHAVE_KERNEL_OPTION_HEADERS -include =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g =
-fno-omit-frame-pointer =
-I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr=
c/sys/GENERIC64vtsc-NODBG -mno-altivec -ffreestanding -fwrapv =
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs =
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline =
-Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ =
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas =
-Wno-error-tautological-compare -Wno-error-empty-body =
-Wno-error-parentheses-equality -Wno-error-unused-function =
-Wno-error-pointer-sign -Wno-error-shift-negative-value -msoft-float =
-std=3Diso9899:1999 -c =
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o
CMD ctfconvert -L VERSION -g hwpmc_e500.o
CWD =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc
TARGET hwpmc_e500.o
-- command output --
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
__asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
^
<inline asm>:1:2: note: instantiated into assembly here
mfpmr 3,400
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: =
unrecognized instruction mnemonic
mtpmr(PMR_PMGC0, pmgc0);
^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
__asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
^
<inline asm>:1:2: note: instantiated into assembly here
mtpmr 400,3
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: =
unrecognized instruction mnemonic
mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE);
^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
__asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
^
<inline asm>:1:2: note: instantiated into assembly here
mtpmr 400,3
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: =
unrecognized instruction mnemonic
pmc_pmlc =3D mfpmr(PMR_PMLCa0);
^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
__asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
^
<inline asm>:1:2: note: instantiated into assembly here
mfpmr 10,144
^
. . .
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Older content:
On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote:
> [Note: At present I can buildworld using WITH_LIB32=3D on
> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a
> minor variant of head -r309179 . That does not work for
> amd64 cross compiling to powerpc64 due to assembler
> notation rejections.]
>=20
> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's
> clang 3.9.0 I get the following sorts of error
> reports, *even building on powerpc64* :
>=20
> --- hwpmc_e500.o ---
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 3,400
> ^
> . . .
>=20
> When I look up these instructions I find that they are not
> classic powerpc instructions:
> ( =
http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd=
f )
>=20
>> Whereas the classic architecture defines special-purpose registers =
(SPRs) and
>> two instructions to access them (Move to Special-Purpose Register =
(mtspr) and
>> Move from Special-Purpose Register (mfspr)), Book E takes that model =
and defines
>> optional device control registers (DCRs) and mtdcr and mfdcr =
instructions, and
>> the EIS-defined performance monitor APU defines performance monitor =
registers
>> (PMRs) and mtpmr and mfpmr instructions, all based on models provided =
by the
>> UISA.
>=20
> . . .
>=20
> Does this imply that clang 3.9.0 needs to support more instructions =
when
> it is targeting FreeBSD for GENERIC64 based builds? (I include =
GENERIC64
> and then override some items for my build activity.)
>=20
> If yes, then someone probably needs to make a list of what =
instructions
> need to be present and have someone submit the list into llvm's =
bugzilla
> and have the submittal listed in:
>=20
> [META] Using Clang as the FreeBSD/ppc system compiler
>=20
> (25780).
>=20
>=20
> If GENERIC64 does not need the likes of hwpmc_e500.o built then some
> work on the build environment to avoid GENERIC64 including things with
> non-classic instruction use would appear to be needed. (No llvm
> involvement for this case.) I doubt this is the case as it would
> seem that the problem would reoccur when alternate KERNCONF's were
> in use instead that do require something like of hwpmc_e500.o to be
> built.
>=20
>=20
> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is =
about
> this issue from the FreeBSD side of things. I just noticed the status
> of the specific instructions involved and also that the cross-build
> and on-powerpc64 build get the same result (unlike the recent
> WITH_LIB32=3D discovery).
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
From owner-freebsd-toolchain@freebsd.org Tue Dec 6 01:42:41 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12753C66F58
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Tue, 6 Dec 2016 01:42:41 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net
[208.70.210.16])
(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 CB89031A
for <freebsd-toolchain@freebsd.org>; Tue, 6 Dec 2016 01:42:40 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 20278 invoked from network); 6 Dec 2016 01:42:39 -0000
Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2)
by 0 (rfx-qmail) with SMTP; 6 Dec 2016 01:42:39 -0000
Received: by mail-cs-02.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Mon, 05 Dec 2016 20:42:46 -0500 (EST)
Received: (qmail 22349 invoked from network); 6 Dec 2016 01:42:37 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Dec 2016 01:42:37 -0000
Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net
[67.170.167.181])
by iron2.pdx.net (Postfix) with ESMTPSA id 24F39EC7977;
Mon, 5 Dec 2016 17:42:29 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
Date: Mon, 5 Dec 2016 17:42:28 -0800
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
To: Roman Divacky <rdivacky@vlakno.cz>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 01:42:41 -0000
On 2016-Dec-5, at 5:16 PM, Mark Millard <markmi at dsl-only.net> wrote:
> Well it looks like:
>=20
> WITHOUT_CROSS_COMPILER=3D
> WITH_SYSTEM_COMPILER=3D
>=20
> ignores the .td file change but
>=20
> WITH_CROSS_COMPILER=3D
> WITHOUT_SYSTEM_COMPILER=3D
>=20
> may use it.
>=20
> I had accidentally used a SRC_CONF_ENV file that
> was of the first form.
>=20
> So I've got a build going based on the 2nd form. . .
No such luck: same type of failure at the same point.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Dec-5, at 4:05 PM, Mark Millard <markmi at dsl-only.net> wrote:
On 2016-Dec-5, at 8:19 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
> Can you try this patch?
>=20
> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> @@ -2373,6 +2373,12 @@
> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
> "mftb $RT, $SPR", IIC_SprMFTB>;
>=20
> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
> + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
> +
> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
> + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
> +
> // A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
> // on a 32-bit target.
> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
Direct use of the patch (put into a file) was rejected:
# patch -p0 < llvmPPCInstrInfo_td.patch=20
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
|+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
--------------------------
Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A...
patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, =
(outs gprc:$RT), (ins i32imm:$SPR),
So I hand put in the extra lines.
I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124
the MFTB line is at line number 2300 while your patch listed:
@@ -2373,6 +2373,12 @@
My edit shows as:
# svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision =
309179)
+++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
@@ -2300,6 +2300,12 @@
def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
"mftb $RT, $SPR", IIC_SprMFTB>;
+def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
+ "mfpmr $RT, $PMRN", IIC_IntGeneral>;
+
+def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
+ "mtpmr $PMRN, $RS", IIC_IntGeneral>;
+
// A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
// on a 32-bit target.
let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
Unfortunately the buildkernel still gets the same errors:
(This was tried after a kernel-toolchain .)
# Meta data file =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met=
a
CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target =
powerpc64-unknown-freebsd12.0 =
--sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp=
c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe =
-fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc =
-DHAVE_KERNEL_OPTION_HEADERS -include =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g =
-fno-omit-frame-pointer =
-I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr=
c/sys/GENERIC64vtsc-NODBG -mno-altivec -ffreestanding -fwrapv =
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs =
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline =
-Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ =
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas =
-Wno-error-tautological-compare -Wno-error-empty-body =
-Wno-error-parentheses-equality -Wno-e
rror-unused-function -Wno-error-pointer-sign =
-Wno-error-shift-negative-value -msoft-float -std=3Diso9899:1999 -c =
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o
CMD ctfconvert -L VERSION -g hwpmc_e500.o
CWD =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc
TARGET hwpmc_e500.o
-- command output --
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
__asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
^
<inline asm>:1:2: note: instantiated into assembly here
mfpmr 3,400
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: =
unrecognized instruction mnemonic
mtpmr(PMR_PMGC0, pmgc0);
^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
__asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
^
<inline asm>:1:2: note: instantiated into assembly here
mtpmr 400,3
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: =
unrecognized instruction mnemonic
mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE);
^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
__asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
^
<inline asm>:1:2: note: instantiated into assembly here
mtpmr 400,3
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: =
unrecognized instruction mnemonic
pmc_pmlc =3D mfpmr(PMR_PMLCa0);
^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
__asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
^
<inline asm>:1:2: note: instantiated into assembly here
mfpmr 10,144
^
. . .
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Older content:
On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote:
> [Note: At present I can buildworld using WITH_LIB32=3D on
> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a
> minor variant of head -r309179 . That does not work for
> amd64 cross compiling to powerpc64 due to assembler
> notation rejections.]
>=20
> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's
> clang 3.9.0 I get the following sorts of error
> reports, *even building on powerpc64* :
>=20
> --- hwpmc_e500.o ---
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 3,400
> ^
> . . .
>=20
> When I look up these instructions I find that they are not
> classic powerpc instructions:
> ( =
http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd=
f )
>=20
>> Whereas the classic architecture defines special-purpose registers =
(SPRs) and
>> two instructions to access them (Move to Special-Purpose Register =
(mtspr) and
>> Move from Special-Purpose Register (mfspr)), Book E takes that model =
and defines
>> optional device control registers (DCRs) and mtdcr and mfdcr =
instructions, and
>> the EIS-defined performance monitor APU defines performance monitor =
registers
>> (PMRs) and mtpmr and mfpmr instructions, all based on models provided =
by the
>> UISA.
>=20
> . . .
>=20
> Does this imply that clang 3.9.0 needs to support more instructions =
when
> it is targeting FreeBSD for GENERIC64 based builds? (I include =
GENERIC64
> and then override some items for my build activity.)
>=20
> If yes, then someone probably needs to make a list of what =
instructions
> need to be present and have someone submit the list into llvm's =
bugzilla
> and have the submittal listed in:
>=20
> [META] Using Clang as the FreeBSD/ppc system compiler
>=20
> (25780).
>=20
>=20
> If GENERIC64 does not need the likes of hwpmc_e500.o built then some
> work on the build environment to avoid GENERIC64 including things with
> non-classic instruction use would appear to be needed. (No llvm
> involvement for this case.) I doubt this is the case as it would
> seem that the problem would reoccur when alternate KERNCONF's were
> in use instead that do require something like of hwpmc_e500.o to be
> built.
>=20
>=20
> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is =
about
> this issue from the FreeBSD side of things. I just noticed the status
> of the specific instructions involved and also that the cross-build
> and on-powerpc64 build get the same result (unlike the recent
> WITH_LIB32=3D discovery).
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
_______________________________________________
freebsd-ppc@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
From owner-freebsd-toolchain@freebsd.org Tue Dec 6 20:44:45 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA8CCC6B336
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Tue, 6 Dec 2016 20:44:45 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 C98031AFA
for <freebsd-toolchain@FreeBSD.org>; Tue, 6 Dec 2016 20:44:45 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB6Kijm9019644
for <freebsd-toolchain@FreeBSD.org>; Tue, 6 Dec 2016 20:44:45 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0:
llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops
Date: Tue, 06 Dec 2016 20:44:46 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: commit-hook@freebsd.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-214902-29464-hqX11K1zHB@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-214902-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-214902-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 20:44:46 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902
--- Comment #6 from commit-hook@freebsd.org ---
A commit references this bug:
Author: dim
Date: Tue Dec 6 20:44:40 UTC 2016
New revision: 309656
URL: https://svnweb.freebsd.org/changeset/base/309656
Log:
During the bootstrap phase, when building the minimal llvm library on
PowerPC, add lib/Support/Atomic.cpp. This is needed because upstream
llvm revision r271821 disabled the use of std::call_once, which causes
some fallback functions from Atomic.cpp to be used instead.
Reported by: Mark Millard
PR: 214902
X-MFC-With: 309124
Changes:
head/lib/clang/libllvmminimal/Makefile
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Tue Dec 6 20:47:00 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15D40C6B3E6
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Tue, 6 Dec 2016 20:47:00 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 0350D1E12
for <freebsd-toolchain@FreeBSD.org>; Tue, 6 Dec 2016 20:47:00 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB6Kkx0Q022864
for <freebsd-toolchain@FreeBSD.org>; Tue, 6 Dec 2016 20:46:59 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0:
llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops
Date: Tue, 06 Dec 2016 20:47:00 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: dim@FreeBSD.org
X-Bugzilla-Status: In Progress
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: dim@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to cc bug_status bug_severity
Message-ID: <bug-214902-29464-Z4GXh8jQyF@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-214902-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-214902-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 20:47:00 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902
Dimitry Andric <dim@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org
|rg |
CC| |dim@FreeBSD.org
Status|New |In Progress
Severity|Affects Only Me |Affects Some People
--- Comment #7 from Dimitry Andric <dim@FreeBSD.org> ---
Mark, can you please verify that r309656 fixes this particular build issue,
when building on PowerPC? I don't have access to any PowerPC hardware.
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Wed Dec 7 19:03:33 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC4A7C6C6A8;
Wed, 7 Dec 2016 19:03:33 +0000 (UTC)
(envelope-from rdivacky@vlakno.cz)
Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224])
by mx1.freebsd.org (Postfix) with ESMTP id 3E26919B0;
Wed, 7 Dec 2016 19:03:32 +0000 (UTC)
(envelope-from rdivacky@vlakno.cz)
Received: by vlakno.cz (Postfix, from userid 1002)
id 12999A35642; Wed, 7 Dec 2016 20:00:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail;
t=1481137257; bh=LSHzhVjJ37HcNPKj3GP6Igcwd4+Wg7AuqVrye5L8fMk=;
h=Date:From:To:Cc:Subject:References:In-Reply-To;
b=gGwcOSriYdgBQ0uHRe6wglrmT3GTHGrRAarp/YjlTG9PsFsdsRjtCqw/fX4nOnMAO
PXfcRIDde15c4w5O3Xc9v+oJkJgwMxadqt7LC6xT1IM6zeWwA4+oZSo8ay9Vop8ZOV
xY6af6KuxjwMBmq5Do2nf/tOjOu/KHgNtCQhf6vI=
Date: Wed, 7 Dec 2016 20:00:57 +0100
From: Roman Divacky <rdivacky@vlakno.cz>
To: Mark Millard <markmi@dsl-only.net>
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
Message-ID: <20161207190057.GA58950@vlakno.cz>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
<D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2016 19:03:33 -0000
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" : "=3Dr"(val) : "K"(reg)); \
val; } )
#define PMR_PMC0 16
int foo()
{
return mfpmr(PMR_PMC0);
}
I can compile it just fine locally. Not sure why it wouldnt work in your ca=
se.
On Mon, Dec 05, 2016 at 05:42:28PM -0800, Mark Millard wrote:
> On 2016-Dec-5, at 5:16 PM, Mark Millard <markmi at dsl-only.net> wrote:
>=20
> > Well it looks like:
> >=20
> > WITHOUT_CROSS_COMPILER=3D
> > WITH_SYSTEM_COMPILER=3D
> >=20
> > ignores the .td file change but
> >=20
> > WITH_CROSS_COMPILER=3D
> > WITHOUT_SYSTEM_COMPILER=3D
> >=20
> > may use it.
> >=20
> > I had accidentally used a SRC_CONF_ENV file that
> > was of the first form.
> >=20
> > So I've got a build going based on the 2nd form. . .
>=20
> No such luck: same type of failure at the same point.
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> On 2016-Dec-5, at 4:05 PM, Mark Millard <markmi at dsl-only.net> wrote:
>=20
> On 2016-Dec-5, at 8:19 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
>=20
> > Can you try this patch?
> >=20
> > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> > @@ -2373,6 +2373,12 @@
> > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
> > "mftb $RT, $SPR", IIC_SprMFTB>;
> >=20
> > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
> > + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
> > +
> > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
> > + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
> > +
> > // A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
> > // on a 32-bit target.
> > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
>=20
> Direct use of the patch (put into a file) was rejected:
>=20
> # patch -p0 < llvmPPCInstrInfo_td.patch=20
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> --------------------------
> Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A...
> patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, (out=
s gprc:$RT), (ins i32imm:$SPR),
>=20
> So I hand put in the extra lines.
>=20
> I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124
> the MFTB line is at line number 2300 while your patch listed:
>=20
> @@ -2373,6 +2373,12 @@
>=20
> My edit shows as:
>=20
> # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 309179)
> +++ 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>;
>=20
> +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 co=
unter
> // on a 32-bit target.
> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
>=20
>=20
> Unfortunately the buildkernel still gets the same errors:
> (This was tried after a kernel-toolchain .)
>=20
> # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.=
powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc=
/hwpmc_e500.o.meta
> CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target powerpc64=
-unknown-freebsd12.0 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_k=
ernel/powerpc.powerpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O=
2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KER=
NEL_OPTION_HEADERS -include /usr/obj/powerpc64vtsc_clang_altbinutils_kernel=
/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/=
src/sys -fno-common -g -fno-omit-frame-pointer -I/usr/obj/powerpc64vtsc_cla=
ng_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG -m=
no-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredun=
dant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoin=
ter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__f=
reebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn=
own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-erro=
r-parentheses-equality -Wno-e
> rror-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-va=
lue -msoft-float -std=3Diso9899:1999 -c /usr/src/sys/modules/hwpmc/../../=
dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o
> CMD ctfconvert -L VERSION -g hwpmc_e500.o
> CWD /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr=
/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc
> TARGET hwpmc_e500.o
> -- command output --
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: un=
recognized instruction mnemonic
> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 3,400
> ^
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: unr=
ecognized instruction mnemonic
> mtpmr(PMR_PMGC0, pmgc0);
> ^
> ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
> __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mtpmr 400,3
> ^
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: unr=
ecognized instruction mnemonic
> mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE);
> ^
> ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
> __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mtpmr 400,3
> ^
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: un=
recognized instruction mnemonic
> pmc_pmlc =3D mfpmr(PMR_PMLCa0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 10,144
> ^
> . . .
>=20
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> Older content:
>=20
> On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote:
> > [Note: At present I can buildworld using WITH_LIB32=3D on
> > powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a
> > minor variant of head -r309179 . That does not work for
> > amd64 cross compiling to powerpc64 due to assembler
> > notation rejections.]
> >=20
> > When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's
> > clang 3.9.0 I get the following sorts of error
> > reports, *even building on powerpc64* :
> >=20
> > --- hwpmc_e500.o ---
> > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
> > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
> > ^
> > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \
> > ^
> > <inline asm>:1:2: note: instantiated into assembly here
> > mfpmr 3,400
> > ^
> > . . .
> >=20
> > When I look up these instructions I find that they are not
> > classic powerpc instructions:
> > ( http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRM=
RM.pdf )
> >=20
> >> Whereas the classic architecture defines special-purpose registers (SP=
Rs) and
> >> two instructions to access them (Move to Special-Purpose Register (mts=
pr) and
> >> Move from Special-Purpose Register (mfspr)), Book E takes that model a=
nd defines
> >> optional device control registers (DCRs) and mtdcr and mfdcr instructi=
ons, and
> >> the EIS-defined performance monitor APU defines performance monitor re=
gisters
> >> (PMRs) and mtpmr and mfpmr instructions, all based on models provided =
by the
> >> UISA.
> >=20
> > . . .
> >=20
> > Does this imply that clang 3.9.0 needs to support more instructions when
> > it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC64
> > and then override some items for my build activity.)
> >=20
> > If yes, then someone probably needs to make a list of what instructions
> > need to be present and have someone submit the list into llvm's bugzilla
> > and have the submittal listed in:
> >=20
> > [META] Using Clang as the FreeBSD/ppc system compiler
> >=20
> > (25780).
> >=20
> >=20
> > If GENERIC64 does not need the likes of hwpmc_e500.o built then some
> > work on the build environment to avoid GENERIC64 including things with
> > non-classic instruction use would appear to be needed. (No llvm
> > involvement for this case.) I doubt this is the case as it would
> > seem that the problem would reoccur when alternate KERNCONF's were
> > in use instead that do require something like of hwpmc_e500.o to be
> > built.
> >=20
> >=20
> > Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is abo=
ut
> > this issue from the FreeBSD side of things. I just noticed the status
> > of the specific instructions involved and also that the cross-build
> > and on-powerpc64 build get the same result (unlike the recent
> > WITH_LIB32=3D discovery).
> >=20
> > =3D=3D=3D
> > Mark Millard
> > markmi at dsl-only.net
>=20
>=20
> _______________________________________________
> freebsd-ppc@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 00:11:58 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 101A4C6C988
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Thu, 8 Dec 2016 00:11:58 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net
[208.70.210.14])
(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 C88277E0
for <freebsd-toolchain@freebsd.org>; Thu, 8 Dec 2016 00:11:57 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 13600 invoked from network); 8 Dec 2016 00:11:50 -0000
Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1)
by 0 (rfx-qmail) with SMTP; 8 Dec 2016 00:11:50 -0000
Received: by rtc-sm-01.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Wed, 07 Dec 2016 19:11:50 -0500 (EST)
Received: (qmail 8231 invoked from network); 8 Dec 2016 00:11:50 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 00:11:50 -0000
Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net
[67.170.167.181])
by iron2.pdx.net (Postfix) with ESMTPSA id AF2CCEC7B39;
Wed, 7 Dec 2016 16:11:49 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <20161207190057.GA58950@vlakno.cz>
Date: Wed, 7 Dec 2016 16:11:48 -0800
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
<D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
<20161207190057.GA58950@vlakno.cz>
To: Roman Divacky <rdivacky@vlakno.cz>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 00:11:58 -0000
On 2016-Dec-7, at 11:00 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
> Can the compiler you built with the patch process this file:
>=20
> 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" : "=3Dr"(val) : "K"(reg)); =
\
> val; } )
>=20
> #define PMR_PMC0 16
>=20
> int foo()
> {
> return mfpmr(PMR_PMC0);
> }
>=20
>=20
> 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.
=3D=3D=3D
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 <markmi at dsl-only.net> =
wrote:
>=20
>> Well it looks like:
>>=20
>> WITHOUT_CROSS_COMPILER=3D
>> WITH_SYSTEM_COMPILER=3D
>>=20
>> ignores the .td file change but
>>=20
>> WITH_CROSS_COMPILER=3D
>> WITHOUT_SYSTEM_COMPILER=3D
>>=20
>> may use it.
>>=20
>> I had accidentally used a SRC_CONF_ENV file that
>> was of the first form.
>>=20
>> So I've got a build going based on the 2nd form. . .
>=20
> No such luck: same type of failure at the same point.
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> On 2016-Dec-5, at 4:05 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
> On 2016-Dec-5, at 8:19 AM, Roman Divacky <rdivacky at vlakno.cz> =
wrote:
>=20
>> Can you try this patch?
>>=20
>> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
>> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
>> @@ -2373,6 +2373,12 @@
>> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
>> "mftb $RT, $SPR", IIC_SprMFTB>;
>>=20
>> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
>> + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
>> +
>> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
>> + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
>> +
>> // A pseudo-instruction used to implement the read of the 64-bit =
cycle counter
>> // on a 32-bit target.
>> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
>=20
> Direct use of the patch (put into a file) was rejected:
>=20
> # patch -p0 < llvmPPCInstrInfo_td.patch=20
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> --------------------------
> Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A...
> patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, =
(outs gprc:$RT), (ins i32imm:$SPR),
>=20
> So I hand put in the extra lines.
>=20
> I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124
> the MFTB line is at line number 2300 while your patch listed:
>=20
> @@ -2373,6 +2373,12 @@
>=20
> My edit shows as:
>=20
> # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision =
309179)
> +++ 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>;
>=20
> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
> + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
> +
> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
> + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
> +
> // A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
> // on a 32-bit target.
> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
>=20
>=20
> Unfortunately the buildkernel still gets the same errors:
> (This was tried after a kernel-toolchain .)
>=20
> # Meta data file =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met=
a
> CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target =
powerpc64-unknown-freebsd12.0 =
--sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp=
c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe =
-fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc =
-DHAVE_KERNEL_OPTION_HEADERS -include =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g =
-fno-omit-frame-pointer =
-I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr=
c/sys/GENERIC64vtsc-NODBG -mno-altivec -ffreestanding -fwrapv =
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs =
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline =
-Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ =
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas =
-Wno-error-tautological-compare -Wno-error-empty-body =
-Wno-error-parentheses-equality -Wno-e
> rror-unused-function -Wno-error-pointer-sign =
-Wno-error-shift-negative-value -msoft-float -std=3Diso9899:1999 -c =
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o
> CMD ctfconvert -L VERSION -g hwpmc_e500.o
> CWD =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc
> TARGET hwpmc_e500.o
> -- command output --
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 3,400
> ^
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: =
unrecognized instruction mnemonic
> mtpmr(PMR_PMGC0, pmgc0);
> ^
> ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
> __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mtpmr 400,3
> ^
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: =
unrecognized instruction mnemonic
> mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE);
> ^
> ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
> __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mtpmr 400,3
> ^
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: =
unrecognized instruction mnemonic
> pmc_pmlc =3D mfpmr(PMR_PMLCa0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 10,144
> ^
> . . .
>=20
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> Older content:
>=20
> On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote:
>> [Note: At present I can buildworld using WITH_LIB32=3D on
>> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a
>> minor variant of head -r309179 . That does not work for
>> amd64 cross compiling to powerpc64 due to assembler
>> notation rejections.]
>>=20
>> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's
>> clang 3.9.0 I get the following sorts of error
>> reports, *even building on powerpc64* :
>>=20
>> --- hwpmc_e500.o ---
>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: =
error: unrecognized instruction mnemonic
>> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
>> ^
>> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
>> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
>> ^
>> <inline asm>:1:2: note: instantiated into assembly here
>> mfpmr 3,400
>> ^
>> . . .
>>=20
>> When I look up these instructions I find that they are not
>> classic powerpc instructions:
>> ( =
http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd=
f )
>>=20
>>> Whereas the classic architecture defines special-purpose registers =
(SPRs) and
>>> two instructions to access them (Move to Special-Purpose Register =
(mtspr) and
>>> Move from Special-Purpose Register (mfspr)), Book E takes that model =
and defines
>>> optional device control registers (DCRs) and mtdcr and mfdcr =
instructions, and
>>> the EIS-defined performance monitor APU defines performance monitor =
registers
>>> (PMRs) and mtpmr and mfpmr instructions, all based on models =
provided by the
>>> UISA.
>>=20
>> . . .
>>=20
>> Does this imply that clang 3.9.0 needs to support more instructions =
when
>> it is targeting FreeBSD for GENERIC64 based builds? (I include =
GENERIC64
>> and then override some items for my build activity.)
>>=20
>> If yes, then someone probably needs to make a list of what =
instructions
>> need to be present and have someone submit the list into llvm's =
bugzilla
>> and have the submittal listed in:
>>=20
>> [META] Using Clang as the FreeBSD/ppc system compiler
>>=20
>> (25780).
>>=20
>>=20
>> If GENERIC64 does not need the likes of hwpmc_e500.o built then some
>> work on the build environment to avoid GENERIC64 including things =
with
>> non-classic instruction use would appear to be needed. (No llvm
>> involvement for this case.) I doubt this is the case as it would
>> seem that the problem would reoccur when alternate KERNCONF's were
>> in use instead that do require something like of hwpmc_e500.o to be
>> built.
>>=20
>>=20
>> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is =
about
>> this issue from the FreeBSD side of things. I just noticed the status
>> of the specific instructions involved and also that the cross-build
>> and on-powerpc64 build get the same result (unlike the recent
>> WITH_LIB32=3D discovery).
>>=20
>> =3D=3D=3D
>> Mark Millard
>> markmi at dsl-only.net
>=20
>=20
> _______________________________________________
> freebsd-ppc@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 03:31:56 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6526C6BF16
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Thu, 8 Dec 2016 03:31:56 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 D57B5120D
for <freebsd-toolchain@FreeBSD.org>; Thu, 8 Dec 2016 03:31:56 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB83Vuj4012484
for <freebsd-toolchain@FreeBSD.org>; Thu, 8 Dec 2016 03:31:56 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386
then aborts (i.e. not killed)
Date: Thu, 08 Dec 2016 03:31:56 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Ports & Packages
X-Bugzilla-Component: Individual Port(s)
X-Bugzilla-Version: Latest
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jbeich@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform
op_sys bug_status bug_severity priority component assigned_to reporter cc
attachments.created
Message-ID: <bug-215136-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 03:31:57 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215136
Bug ID: 215136
Summary: graphics/colmap: clang -O2 runs out of memory on i386
then aborts (i.e. not killed)
Product: Ports & Packages
Version: Latest
Hardware: i386
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: Individual Port(s)
Assignee: freebsd-ports-bugs@FreeBSD.org
Reporter: jbeich@FreeBSD.org
CC: freebsd-toolchain@FreeBSD.org
Created attachment 177777
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D177777&action=
=3Dedit
src/util/camera_specs.cc (preprocessed, compressed)
$ cd /usr/ports/graphics/colmap
$ rm files/patch-src_util_CMakeLists.txt
$ make
[...]
1. <eof> parser at end of file
2. Per-module optimization passes
3. Running pass 'CallGraph Pass Manager' on module
'src/util/camera_specs.cc'.
4. Running pass 'Value Propagation' on function
'@_ZN6colmap21InitializeCameraSpecsEv'
c++: error: unable to execute command: Abort trap
c++: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: i386-unknown-freebsd10.1
Thread model: posix
--=20
You are receiving this mail because:
You are on the CC list for the bug.=
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 03:32:50 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 731FAC6BF72
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Thu, 8 Dec 2016 03:32:50 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 621431447
for <freebsd-toolchain@FreeBSD.org>; Thu, 8 Dec 2016 03:32:50 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB83Womf037824
for <freebsd-toolchain@FreeBSD.org>; Thu, 8 Dec 2016 03:32:50 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386
then aborts (i.e. not killed)
Date: Thu, 08 Dec 2016 03:32:50 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Ports & Packages
X-Bugzilla-Component: Individual Port(s)
X-Bugzilla-Version: Latest
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jbeich@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-215136-29464-2lXsNsOrSp@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215136-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215136-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 03:32:50 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215136
--- Comment #1 from Jan Beich (mail not working) <jbeich@FreeBSD.org> ---
Created attachment 177778
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D177778&action=
=3Dedit
command line args (for clang 3.8+)
--=20
You are receiving this mail because:
You are on the CC list for the bug.=
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 03:34:00 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADA4FC6BFF2
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Thu, 8 Dec 2016 03:34:00 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 9CBD614CD
for <freebsd-toolchain@FreeBSD.org>; Thu, 8 Dec 2016 03:34:00 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB83Y0ng068927
for <freebsd-toolchain@FreeBSD.org>; Thu, 8 Dec 2016 03:34:00 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386
then aborts (i.e. not killed)
Date: Thu, 08 Dec 2016 03:34:00 +0000
X-Bugzilla-Reason: CC AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Ports & Packages
X-Bugzilla-Component: Individual Port(s)
X-Bugzilla-Version: Latest
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jbeich@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to cc
Message-ID: <bug-215136-29464-cB9kNe5kJh@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215136-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215136-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 03:34:00 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215136
Jan Beich (mail not working) <jbeich@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-ports-bugs@FreeBSD. |freebsd-toolchain@FreeBSD.o
|org |rg
CC|freebsd-toolchain@FreeBSD.o |
|rg |
--=20
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 05:52:51 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EDD8C6C0A9
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Thu, 8 Dec 2016 05:52:51 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-12.reflexion.net
[208.70.210.12])
(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 024B39C0
for <freebsd-toolchain@freebsd.org>; Thu, 8 Dec 2016 05:52:50 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 25494 invoked from network); 8 Dec 2016 05:52:57 -0000
Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1)
by 0 (rfx-qmail) with SMTP; 8 Dec 2016 05:52:57 -0000
Received: by rtc-sm-01.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Thu, 08 Dec 2016 00:52:48 -0500 (EST)
Received: (qmail 14381 invoked from network); 8 Dec 2016 05:52:48 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 05:52:48 -0000
Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net
[67.170.167.181])
by iron2.pdx.net (Postfix) with ESMTPSA id C0A77EC861A;
Wed, 7 Dec 2016 21:52:47 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net>
Date: Wed, 7 Dec 2016 21:52:47 -0800
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
<D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
<20161207190057.GA58950@vlakno.cz>
<E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net>
To: Roman Divacky <rdivacky@vlakno.cz>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 05:52:51 -0000
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/sys/modules/zfs/Makefile (revision 309656)
+++ /usr/src/sys/modules/zfs/Makefile (working copy)
@@ -93,9 +93,9 @@
CFLAGS+=3D-I${SUNW}/common
CFLAGS+=3D-DBUILDING_ZFS
=20
-.if ${MACHINE_ARCH} =3D=3D "powerpc64"
-CFLAGS+=3D-mminimal-toc
-.endif
+#.if ${MACHINE_ARCH} =3D=3D "powerpc64"
+#CFLAGS+=3D-mminimal-toc
+#.endif
=20
.ifdef ZFS_DEBUG
CFLAGS+=3D-DDEBUG=3D1
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).
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Dec-7, at 4:11 PM, Mark Millard <markmi@dsl-only.net> wrote:
On 2016-Dec-7, at 11:00 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
> Can the compiler you built with the patch process this file:
>=20
> 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" : "=3Dr"(val) : "K"(reg)); =
\
> val; } )
>=20
> #define PMR_PMC0 16
>=20
> int foo()
> {
> return mfpmr(PMR_PMC0);
> }
>=20
>=20
> 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.
=3D=3D=3D
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 <markmi at dsl-only.net> =
wrote:
>=20
>> Well it looks like:
>>=20
>> WITHOUT_CROSS_COMPILER=3D
>> WITH_SYSTEM_COMPILER=3D
>>=20
>> ignores the .td file change but
>>=20
>> WITH_CROSS_COMPILER=3D
>> WITHOUT_SYSTEM_COMPILER=3D
>>=20
>> may use it.
>>=20
>> I had accidentally used a SRC_CONF_ENV file that
>> was of the first form.
>>=20
>> So I've got a build going based on the 2nd form. . .
>=20
> No such luck: same type of failure at the same point.
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> On 2016-Dec-5, at 4:05 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
> On 2016-Dec-5, at 8:19 AM, Roman Divacky <rdivacky at vlakno.cz> =
wrote:
>=20
>> Can you try this patch?
>>=20
>> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
>> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
>> @@ -2373,6 +2373,12 @@
>> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
>> "mftb $RT, $SPR", IIC_SprMFTB>;
>>=20
>> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
>> + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
>> +
>> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
>> + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
>> +
>> // A pseudo-instruction used to implement the read of the 64-bit =
cycle counter
>> // on a 32-bit target.
>> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
>=20
> Direct use of the patch (put into a file) was rejected:
>=20
> # patch -p0 < llvmPPCInstrInfo_td.patch=20
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> --------------------------
> Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A...
> patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, =
(outs gprc:$RT), (ins i32imm:$SPR),
>=20
> So I hand put in the extra lines.
>=20
> I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124
> the MFTB line is at line number 2300 while your patch listed:
>=20
> @@ -2373,6 +2373,12 @@
>=20
> My edit shows as:
>=20
> # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision =
309179)
> +++ 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>;
>=20
> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
> + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
> +
> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
> + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
> +
> // A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
> // on a 32-bit target.
> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
>=20
>=20
> Unfortunately the buildkernel still gets the same errors:
> (This was tried after a kernel-toolchain .)
>=20
> # Meta data file =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met=
a
> CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target =
powerpc64-unknown-freebsd12.0 =
--sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp=
c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe =
-fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc =
-DHAVE_KERNEL_OPTION_HEADERS -include =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g =
-fno-omit-frame-pointer =
-I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr=
c/sys/GENERIC64vtsc-NODBG -mno-altivec -ffreestanding -fwrapv =
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs =
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline =
-Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ =
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas =
-Wno-error-tautological-compare -Wno-error-empty-body =
-Wno-error-parentheses-equality -Wno-e
> rror-unused-function -Wno-error-pointer-sign =
-Wno-error-shift-negative-value -msoft-float -std=3Diso9899:1999 -c =
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o
> CMD ctfconvert -L VERSION -g hwpmc_e500.o
> CWD =
/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc
> TARGET hwpmc_e500.o
> -- command output --
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 3,400
> ^
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: =
unrecognized instruction mnemonic
> mtpmr(PMR_PMGC0, pmgc0);
> ^
> ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
> __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mtpmr 400,3
> ^
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: =
unrecognized instruction mnemonic
> mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE);
> ^
> ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
> __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mtpmr 400,3
> ^
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: =
unrecognized instruction mnemonic
> pmc_pmlc =3D mfpmr(PMR_PMLCa0);
> ^
> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
> ^
> <inline asm>:1:2: note: instantiated into assembly here
> mfpmr 10,144
> ^
> . . .
>=20
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> Older content:
>=20
> On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote:
>> [Note: At present I can buildworld using WITH_LIB32=3D on
>> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a
>> minor variant of head -r309179 . That does not work for
>> amd64 cross compiling to powerpc64 due to assembler
>> notation rejections.]
>>=20
>> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's
>> clang 3.9.0 I get the following sorts of error
>> reports, *even building on powerpc64* :
>>=20
>> --- hwpmc_e500.o ---
>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: =
error: unrecognized instruction mnemonic
>> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
>> ^
>> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
>> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); =
\
>> ^
>> <inline asm>:1:2: note: instantiated into assembly here
>> mfpmr 3,400
>> ^
>> . . .
>>=20
>> When I look up these instructions I find that they are not
>> classic powerpc instructions:
>> ( =
http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd=
f )
>>=20
>>> Whereas the classic architecture defines special-purpose registers =
(SPRs) and
>>> two instructions to access them (Move to Special-Purpose Register =
(mtspr) and
>>> Move from Special-Purpose Register (mfspr)), Book E takes that model =
and defines
>>> optional device control registers (DCRs) and mtdcr and mfdcr =
instructions, and
>>> the EIS-defined performance monitor APU defines performance monitor =
registers
>>> (PMRs) and mtpmr and mfpmr instructions, all based on models =
provided by the
>>> UISA.
>>=20
>> . . .
>>=20
>> Does this imply that clang 3.9.0 needs to support more instructions =
when
>> it is targeting FreeBSD for GENERIC64 based builds? (I include =
GENERIC64
>> and then override some items for my build activity.)
>>=20
>> If yes, then someone probably needs to make a list of what =
instructions
>> need to be present and have someone submit the list into llvm's =
bugzilla
>> and have the submittal listed in:
>>=20
>> [META] Using Clang as the FreeBSD/ppc system compiler
>>=20
>> (25780).
>>=20
>>=20
>> If GENERIC64 does not need the likes of hwpmc_e500.o built then some
>> work on the build environment to avoid GENERIC64 including things =
with
>> non-classic instruction use would appear to be needed. (No llvm
>> involvement for this case.) I doubt this is the case as it would
>> seem that the problem would reoccur when alternate KERNCONF's were
>> in use instead that do require something like of hwpmc_e500.o to be
>> built.
>>=20
>>=20
>> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is =
about
>> this issue from the FreeBSD side of things. I just noticed the status
>> of the specific instructions involved and also that the cross-build
>> and on-powerpc64 build get the same result (unlike the recent
>> WITH_LIB32=3D discovery).
>>=20
>> =3D=3D=3D
>> Mark Millard
>> markmi at dsl-only.net
>=20
>=20
> _______________________________________________
> freebsd-ppc@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 18:58:12 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14F0BC6DE98;
Thu, 8 Dec 2016 18:58:12 +0000 (UTC)
(envelope-from rdivacky@vlakno.cz)
Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224])
by mx1.freebsd.org (Postfix) with ESMTP id 8B9EB182F;
Thu, 8 Dec 2016 18:58:10 +0000 (UTC)
(envelope-from rdivacky@vlakno.cz)
Received: by vlakno.cz (Postfix, from userid 1002)
id 67BA7A35631; Thu, 8 Dec 2016 19:55:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail;
t=1481223341; bh=2GbIgL5ZC8TjiVdj5Et8i5E/lPOPVBJp1AI+hlwlokw=;
h=Date:From:To:Cc:Subject:References:In-Reply-To;
b=eFmLHLjMn6r7HElN9O3IbeYsnyYJN9JyT4W/j4R5QGz0YNfWbi3INK6/bM9yc1GiK
LQRz3YRQHW1jyEShUWTj2IYXGgh66wwCLFrzT/INxTjglKllT4qIyPH8hoF5g/KOYf
kTKLApU30Ril7fhTmIQkYWys/2VmPANvnsgvn3T4=
Date: Thu, 8 Dec 2016 19:55:41 +0100
From: Roman Divacky <rdivacky@vlakno.cz>
To: Mark Millard <markmi@dsl-only.net>
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
Message-ID: <20161208185541.GA33364@vlakno.cz>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
<D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
<20161207190057.GA58950@vlakno.cz>
<E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net>
<CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 18:58:12 -0000
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]:
>=20
> I commented out the one -mminimal-toc use in the modules and tried
> buildkernel again (cross build).
>=20
> It reached the end. But it dies immediately if I try to
> boot it after installing a copy.
>=20
> This was based on:
>=20
> # svnlite diff /usr/src/sys/modules/zfs/Makefile
> Index: /usr/src/sys/modules/zfs/Makefile
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/src/sys/modules/zfs/Makefile (revision 309656)
> +++ /usr/src/sys/modules/zfs/Makefile (working copy)
> @@ -93,9 +93,9 @@
> CFLAGS+=3D-I${SUNW}/common
> CFLAGS+=3D-DBUILDING_ZFS
> =20
> -.if ${MACHINE_ARCH} =3D=3D "powerpc64"
> -CFLAGS+=3D-mminimal-toc
> -.endif
> +#.if ${MACHINE_ARCH} =3D=3D "powerpc64"
> +#CFLAGS+=3D-mminimal-toc
> +#.endif
> =20
> .ifdef ZFS_DEBUG
> CFLAGS+=3D-DDEBUG=3D1
>=20
> as well as your .td file patch.
>=20
> zfs is not in use in the configuration: it just
> uses ufs.
>=20
> 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).
>=20
>=20
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> On 2016-Dec-7, at 4:11 PM, Mark Millard <markmi@dsl-only.net> wrote:
>=20
> On 2016-Dec-7, at 11:00 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
>=20
> > Can the compiler you built with the patch process this file:
> >=20
> > 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" : "=3Dr"(val) : "K"(reg)); =
\
> > val; } )
> >=20
> > #define PMR_PMC0 16
> >=20
> > int foo()
> > {
> > return mfpmr(PMR_PMC0);
> > }
> >=20
> >=20
> > I can compile it just fine locally. Not sure why it wouldnt work in you=
r case.
>=20
> I separately had helped with testing for bugzilla 214902
> and so had updated to head -r309656 so the context was
> different.
>=20
> But I figured out the .td file related issue on powerpc64.
>=20
> 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.)
>=20
> So my buildkernel was using an unpatched compiler when
> I tried kernel-toolchain then buildkernel.
>=20
> This was visible in the .meta file part of my report on the
> problem. It showed:
>=20
> > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/
>=20
>=20
> instead of having the path to the bootstrap compiler.
>=20
> 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.
>=20
> Based on use of compilers that actually have your
> patch in them. . .
>=20
> 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.
>=20
> Sorry for the extra noise in reporting on your patch.
>=20
>=20
> 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.
>=20
> 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.
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> Older material. . .
>=20
> On Mon, Dec 05, 2016 at 05:42:28PM -0800, Mark Millard wrote:
> > On 2016-Dec-5, at 5:16 PM, Mark Millard <markmi at dsl-only.net> wrote:
> >=20
> >> Well it looks like:
> >>=20
> >> WITHOUT_CROSS_COMPILER=3D
> >> WITH_SYSTEM_COMPILER=3D
> >>=20
> >> ignores the .td file change but
> >>=20
> >> WITH_CROSS_COMPILER=3D
> >> WITHOUT_SYSTEM_COMPILER=3D
> >>=20
> >> may use it.
> >>=20
> >> I had accidentally used a SRC_CONF_ENV file that
> >> was of the first form.
> >>=20
> >> So I've got a build going based on the 2nd form. . .
> >=20
> > No such luck: same type of failure at the same point.
> >=20
> > =3D=3D=3D
> > Mark Millard
> > markmi at dsl-only.net
> >=20
> > On 2016-Dec-5, at 4:05 PM, Mark Millard <markmi at dsl-only.net> wrote:
> >=20
> > On 2016-Dec-5, at 8:19 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
> >=20
> >> Can you try this patch?
> >>=20
> >> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> >> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> >> @@ -2373,6 +2373,12 @@
> >> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
> >> "mftb $RT, $SPR", IIC_SprMFTB>;
> >>=20
> >> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
> >> + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
> >> +
> >> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
> >> + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
> >> +
> >> // A pseudo-instruction used to implement the read of the 64-bit cycle=
counter
> >> // on a 32-bit target.
> >> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
> >=20
> > Direct use of the patch (put into a file) was rejected:
> >=20
> > # patch -p0 < llvmPPCInstrInfo_td.patch=20
> > Hmm... Looks like a unified diff to me...
> > The text leading up to this was:
> > --------------------------
> > |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> > |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
> > --------------------------
> > Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A...
> > patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, (o=
uts gprc:$RT), (ins i32imm:$SPR),
> >=20
> > So I hand put in the extra lines.
> >=20
> > I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124
> > the MFTB line is at line number 2300 while your patch listed:
> >=20
> > @@ -2373,6 +2373,12 @@
> >=20
> > My edit shows as:
> >=20
> > # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> > Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 309179)
> > +++ 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>;
> >=20
> > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
> > + "mfpmr $RT, $PMRN", IIC_IntGeneral>;
> > +
> > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
> > + "mtpmr $PMRN, $RS", IIC_IntGeneral>;
> > +
> > // A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
> > // on a 32-bit target.
> > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
> >=20
> >=20
> > Unfortunately the buildkernel still gets the same errors:
> > (This was tried after a kernel-toolchain .)
> >=20
> > # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerp=
c.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwp=
mc/hwpmc_e500.o.meta
> > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target powerpc=
64-unknown-freebsd12.0 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils=
_kernel/powerpc.powerpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -=
O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KE=
RNEL_OPTION_HEADERS -include /usr/obj/powerpc64vtsc_clang_altbinutils_kerne=
l/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr=
/src/sys -fno-common -g -fno-omit-frame-pointer -I/usr/obj/powerpc64vtsc_cl=
ang_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG -=
mno-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredu=
ndant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoi=
nter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__=
freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk=
nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-err=
or-parentheses-equality -Wno-e
> > rror-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-=
value -msoft-float -std=3Diso9899:1999 -c /usr/src/sys/modules/hwpmc/../.=
=2E/dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o
> > CMD ctfconvert -L VERSION -g hwpmc_e500.o
> > CWD /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/u=
sr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc
> > TARGET hwpmc_e500.o
> > -- command output --
> > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: =
unrecognized instruction mnemonic
> > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
> > ^
> > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \
> > ^
> > <inline asm>:1:2: note: instantiated into assembly here
> > mfpmr 3,400
> > ^
> > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: u=
nrecognized instruction mnemonic
> > mtpmr(PMR_PMGC0, pmgc0);
> > ^
> > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
> > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> > ^
> > <inline asm>:1:2: note: instantiated into assembly here
> > mtpmr 400,3
> > ^
> > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: u=
nrecognized instruction mnemonic
> > mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE);
> > ^
> > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
> > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> > ^
> > <inline asm>:1:2: note: instantiated into assembly here
> > mtpmr 400,3
> > ^
> > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: =
unrecognized instruction mnemonic
> > pmc_pmlc =3D mfpmr(PMR_PMLCa0);
> > ^
> > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \
> > ^
> > <inline asm>:1:2: note: instantiated into assembly here
> > mfpmr 10,144
> > ^
> > . . .
> >=20
> >=20
> > =3D=3D=3D
> > Mark Millard
> > markmi at dsl-only.net
> >=20
> > Older content:
> >=20
> > On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote:
> >> [Note: At present I can buildworld using WITH_LIB32=3D on
> >> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a
> >> minor variant of head -r309179 . That does not work for
> >> amd64 cross compiling to powerpc64 due to assembler
> >> notation rejections.]
> >>=20
> >> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's
> >> clang 3.9.0 I get the following sorts of error
> >> reports, *even building on powerpc64* :
> >>=20
> >> --- hwpmc_e500.o ---
> >> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error:=
unrecognized instruction mnemonic
> >> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0);
> >> ^
> >> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> >> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \
> >> ^
> >> <inline asm>:1:2: note: instantiated into assembly here
> >> mfpmr 3,400
> >> ^
> >> . . .
> >>=20
> >> When I look up these instructions I find that they are not
> >> classic powerpc instructions:
> >> ( http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPR=
MRM.pdf )
> >>=20
> >>> Whereas the classic architecture defines special-purpose registers (S=
PRs) and
> >>> two instructions to access them (Move to Special-Purpose Register (mt=
spr) and
> >>> Move from Special-Purpose Register (mfspr)), Book E takes that model =
and defines
> >>> optional device control registers (DCRs) and mtdcr and mfdcr instruct=
ions, and
> >>> the EIS-defined performance monitor APU defines performance monitor r=
egisters
> >>> (PMRs) and mtpmr and mfpmr instructions, all based on models provided=
by the
> >>> UISA.
> >>=20
> >> . . .
> >>=20
> >> Does this imply that clang 3.9.0 needs to support more instructions wh=
en
> >> it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC=
64
> >> and then override some items for my build activity.)
> >>=20
> >> If yes, then someone probably needs to make a list of what instructions
> >> need to be present and have someone submit the list into llvm's bugzil=
la
> >> and have the submittal listed in:
> >>=20
> >> [META] Using Clang as the FreeBSD/ppc system compiler
> >>=20
> >> (25780).
> >>=20
> >>=20
> >> If GENERIC64 does not need the likes of hwpmc_e500.o built then some
> >> work on the build environment to avoid GENERIC64 including things with
> >> non-classic instruction use would appear to be needed. (No llvm
> >> involvement for this case.) I doubt this is the case as it would
> >> seem that the problem would reoccur when alternate KERNCONF's were
> >> in use instead that do require something like of hwpmc_e500.o to be
> >> built.
> >>=20
> >>=20
> >> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is ab=
out
> >> this issue from the FreeBSD side of things. I just noticed the status
> >> of the specific instructions involved and also that the cross-build
> >> and on-powerpc64 build get the same result (unlike the recent
> >> WITH_LIB32=3D discovery).
> >>=20
> >> =3D=3D=3D
> >> Mark Millard
> >> markmi at dsl-only.net
> >=20
> >=20
> > _______________________________________________
> > freebsd-ppc@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 21:02:47 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1C31C6EAE9
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Thu, 8 Dec 2016 21:02:47 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 90C97A70
for <freebsd-toolchain@FreeBSD.org>; Thu, 8 Dec 2016 21:02:47 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB8L2llD026443
for <freebsd-toolchain@FreeBSD.org>; Thu, 8 Dec 2016 21:02:47 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386
then aborts (i.e. not killed)
Date: Thu, 08 Dec 2016 21:02:47 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Ports & Packages
X-Bugzilla-Component: Individual Port(s)
X-Bugzilla-Version: Latest
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: dim@FreeBSD.org
X-Bugzilla-Status: In Progress
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: dim@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc assigned_to bug_status
Message-ID: <bug-215136-29464-lqxTqVvRF4@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215136-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215136-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 21:02:47 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215136
Dimitry Andric <dim@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dim@FreeBSD.org
Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org
|rg |
Status|New |In Progress
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 22:10:41 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FF32C6EF26
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Thu, 8 Dec 2016 22:10:41 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-71.reflexion.net
[208.70.210.71])
(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 57E94E2E
for <freebsd-toolchain@freebsd.org>; Thu, 8 Dec 2016 22:10:40 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 6627 invoked from network); 8 Dec 2016 22:03:59 -0000
Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1)
by 0 (rfx-qmail) with SMTP; 8 Dec 2016 22:03:59 -0000
Received: by rtc-sm-01.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Thu, 08 Dec 2016 17:03:59 -0500 (EST)
Received: (qmail 22978 invoked from network); 8 Dec 2016 22:03:59 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 22:03:59 -0000
Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net
[67.170.167.181])
by iron2.pdx.net (Postfix) with ESMTPSA id CA579EC9142;
Thu, 8 Dec 2016 14:03:58 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <20161208185541.GA33364@vlakno.cz>
Date: Thu, 8 Dec 2016 14:03:58 -0800
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E49F7EE4-7A62-4601-98DC-4C4791B7158D@dsl-only.net>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
<D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
<20161207190057.GA58950@vlakno.cz>
<E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net>
<CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net>
<20161208185541.GA33364@vlakno.cz>
To: Roman Divacky <rdivacky@vlakno.cz>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 22:10:41 -0000
[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 <rdivacky at vlakno.cz> 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=3D 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=3D0xf851a8+0x42dd98 =
syms=3D[0x8+0xd6848+0x8+0xf1137]
/boot/entropy size=3D0x1000
Booting. . .
Kernel entry at 0x100160
Invalid memory access at %SSR0: 00000000.001001b0 =
%SRR1:90000000.00003030
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
=46rom objdump for the above failing boot
but with notes added:
(Note: booting xtoolchain kernel starts at
0000000000100120 instead; relative
offsets are unchanged and the code
is mostly the same.)
Disassembly of section .text:
0000000000100160 <.__start> mfmsr r20
0000000000100164 <.__start+0x4> li r21,1
0000000000100168 <.__start+0x8> rldimi r20,r21,63,0
000000000010016c <.__start+0xc> mtmsrd r20
0000000000100170 <.__start+0x10> isync
0000000000100174 <.__start+0x14> nop
0000000000100178 <.__start+0x18> b 0000000000100180 =
<.__start+0x20>
000000000010017c <.__start+0x1c> nop
0000000000100180 <.__start+0x20> nop
0000000000100184 <.__start+0x24> bl 0000000000100190 =
<.__start+0x30>
0000000000100188 <.__start+0x28> .long 0x0
000000000010018c <.__start+0x2c> .long 0xf8ce78 =20
booting xtoolchain based kernel has: 0xfebeb8 above <<<=3D=3D=3D =
note
0000000000100190 <.__start+0x30> mflr r2
0000000000100194 <.__start+0x34> ld r1,0(r2)
0000000000100198 <.__start+0x38> add r2,r1,r2
000000000010019c <.__start+0x3c> ld r31,-32768(r2)
00000000001001a0 <.__start+0x40> subf r31,r31,r2
00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D =
!!!!!
booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D =
!!!!!
00000000001001a8 <.__start+0x48> addi r1,r1,16288
00000000001001ac <.__start+0x4c> add r1,r1,r31
00000000001001b0 <.__start+0x50> std r3,48(r1)
SRR0 points at the above instruction
(I stopped comparing to the booting xtoolchain
based code after this.)
00000000001001b4 <.__start+0x54> std r4,56(r1)
00000000001001b8 <.__start+0x58> std r5,64(r1)
00000000001001bc <.__start+0x5c> std r6,72(r1)
00000000001001c0 <.__start+0x60> bl 00000000001001cc =
<.__start+0x6c>
00000000001001c4 <.__start+0x64> .long 0x0
00000000001001c8 <.__start+0x68> .long 0xf84ed4
00000000001001cc <.__start+0x6c> mflr r3
00000000001001d0 <.__start+0x70> ld r4,0(r3)
00000000001001d4 <.__start+0x74> add r3,r4,r3
00000000001001d8 <.__start+0x78> mr r4,r31
00000000001001dc <.__start+0x7c> bl 0000000000b18ebc =
<.elf_reloc_self>
00000000001001e0 <.__start+0x80> nop
00000000001001e4 <.__start+0x84> ld r3,48(r1)
00000000001001e8 <.__start+0x88> ld r4,56(r1)
00000000001001ec <.__start+0x8c> ld r5,64(r1)
00000000001001f0 <.__start+0x90> ld r6,72(r1)
00000000001001f4 <.__start+0x94> mr r4,r2
00000000001001f8 <.__start+0x98> bl 0000000000b1e980 =
<.powerpc_init>
00000000001001fc <.__start+0x9c> nop
0000000000100200 <.__start+0xa0> mr r1,r3
0000000000100204 <.__start+0xa4> li r3,0
0000000000100208 <.__start+0xa8> std r3,0(r1)
000000000010020c <.__start+0xac> bl 00000000005c4af8 <.mi_startup>
0000000000100210 <.__start+0xb0> nop
0000000000100214 <.__start+0xb4> b 0000000000100214 =
<.__start+0xb4>
For using WITH_BINUTILS_BOOTSTRAP=3D 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=3D0xfd6318+0x42dda8 =
syms=3D[0x8+0xd6860+0x8+0xf1193]
/boot/entropy size=3D0x1000
Booting. . .
Kernel entry at 0x100160
Invalid memory access at %SSR0: 00000000.00000000 =
%SRR1:10000000.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.
(=46rom objdump.) Note: the same 0(r2) vs. -32760(r2) oddity
exists in the start routine as well.
Disassembly of section .text:
0000000000100160 <.__start-0x2030> std r2,40(r1)
0000000000100164 <.__start-0x202c> addis r2,r2,1
0000000000100168 <.__start-0x2028> addi r2,r2,-8
000000000010016c <.__start-0x2024> b 0000000000b2c8e0 =
<.cpu_switch>
0000000000100170 <.__start-0x2020> std r2,40(r1)
0000000000100174 <.__start-0x201c> addis r2,r2,1
0000000000100178 <.__start-0x2018> addi r2,r2,-8
000000000010017c <.__start-0x2014> b 0000000000ade6c8 =
<.sf_buf_alloc>
0000000000100180 <.__start-0x2010> std r2,40(r1)
0000000000100184 <.__start-0x200c> addis r2,r2,1
0000000000100188 <.__start-0x2008> addi r2,r2,-8
000000000010018c <.__start-0x2004> b 0000000000a83f78 =
<.vm_fault_hold>
0000000000100190 <.__start-0x2000> std r2,40(r1)
0000000000100194 <.__start-0x1ffc> addis r2,r2,1
0000000000100198 <.__start-0x1ff8> addi r2,r2,-8
000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 =
<.fill_regs32>
00000000001001a0 <.__start-0x1ff0> std r2,40(r1)
00000000001001a4 <.__start-0x1fec> addis r2,r2,1
00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8
00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 =
<.casueword32>
00000000001001b0 <.__start-0x1fe0> std r2,40(r1)
00000000001001b4 <.__start-0x1fdc> addis r2,r2,1
00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8
00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 =
<.kmap_free_wakeup>
. . .
0000000000102190 <.__start> mfmsr r20
0000000000102194 <.__start+0x4> li r21,1
0000000000102198 <.__start+0x8> rldimi r20,r21,63,0
000000000010219c <.__start+0xc> mtmsrd r20
00000000001021a0 <.__start+0x10> isync
00000000001021a4 <.__start+0x14> nop
00000000001021a8 <.__start+0x18> b 00000000001021b0 =
<.__start+0x20>
00000000001021ac <.__start+0x1c> nop
00000000001021b0 <.__start+0x20> nop
00000000001021b4 <.__start+0x24> bl 00000000001021c0 =
<.__start+0x30>
00000000001021b8 <.__start+0x28> .long 0x0
00000000001021bc <.__start+0x2c> .long 0xfc8e48
00000000001021c0 <.__start+0x30> mflr r2
00000000001021c4 <.__start+0x34> ld r1,0(r2)
00000000001021c8 <.__start+0x38> add r2,r1,r2
00000000001021cc <.__start+0x3c> ld r31,-32768(r2)
00000000001021d0 <.__start+0x40> subf r31,r31,r2
00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. =
-32760 oddity!!!
00000000001021d8 <.__start+0x48> addi r1,r1,16288
00000000001021dc <.__start+0x4c> add r1,r1,r31
00000000001021e0 <.__start+0x50> std r3,48(r1)
00000000001021e4 <.__start+0x54> std r4,56(r1)
00000000001021e8 <.__start+0x58> std r5,64(r1)
00000000001021ec <.__start+0x5c> std r6,72(r1)
00000000001021f0 <.__start+0x60> bl 00000000001021fc =
<.__start+0x6c>
00000000001021f4 <.__start+0x64> .long 0x0
00000000001021f8 <.__start+0x68> .long 0xfd4014
00000000001021fc <.__start+0x6c> mflr r3
0000000000102200 <.__start+0x70> ld r4,0(r3)
0000000000102204 <.__start+0x74> add r3,r4,r3
0000000000102208 <.__start+0x78> mr r4,r31
000000000010220c <.__start+0x7c> bl 0000000000101a20 <begin+0x1a20>
0000000000102210 <.__start+0x80> ld r2,40(r1)
0000000000102214 <.__start+0x84> ld r3,48(r1)
0000000000102218 <.__start+0x88> ld r4,56(r1)
000000000010221c <.__start+0x8c> ld r5,64(r1)
0000000000102220 <.__start+0x90> ld r6,72(r1)
0000000000102224 <.__start+0x94> mr r4,r2
0000000000102228 <.__start+0x98> bl 00000000001019a0 <begin+0x19a0>
000000000010222c <.__start+0x9c> ld r2,40(r1)
0000000000102230 <.__start+0xa0> mr r1,r3
0000000000102234 <.__start+0xa4> li r3,0
0000000000102238 <.__start+0xa8> std r3,0(r1)
000000000010223c <.__start+0xac> bl 00000000005c6b28 <.mi_startup>
0000000000102240 <.__start+0xb0> nop
0000000000102244 <.__start+0xb4> b 0000000000102244 =
<.__start+0xb4>
Who is most appropriate to send such information to for powerpc64?
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 22:17:28 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3905C6D13E;
Thu, 8 Dec 2016 22:17:28 +0000 (UTC)
(envelope-from rdivacky@vlakno.cz)
Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224])
by mx1.freebsd.org (Postfix) with ESMTP id 6E710115A;
Thu, 8 Dec 2016 22:17:27 +0000 (UTC)
(envelope-from rdivacky@vlakno.cz)
Received: by vlakno.cz (Postfix, from userid 1002)
id 6DA4DA35642; Thu, 8 Dec 2016 23:14:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail;
t=1481235292; bh=AEbR7wvCJ6r5zGGvCrm0og9sNSK7q6/6kCHYiacjU8M=;
h=Date:From:To:Cc:Subject:References:In-Reply-To;
b=HIsrZ7BW1vK26fETY+xxXCgMO0gszEND8xE1DwvMLMc/9jSn+YTiar/GMxZROSXVx
Q4p5rj4TbzX4ZBT9zPtDhskcK6eEpBE6Eias6WjcfYrlCGGJO+LP+M3e+quFOnTWuM
eowpiP9+ONl4MWqJyRKaECDqcq34jf8tdKperq4s=
Date: Thu, 8 Dec 2016 23:14:52 +0100
From: Roman Divacky <rdivacky@vlakno.cz>
To: Mark Millard <markmi@dsl-only.net>
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, nwhitehorn@freebsd.org
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
Message-ID: <20161208221452.GA42380@vlakno.cz>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
<D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
<20161207190057.GA58950@vlakno.cz>
<E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net>
<CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net>
<20161208185541.GA33364@vlakno.cz>
<E49F7EE4-7A62-4601-98DC-4C4791B7158D@dsl-only.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E49F7EE4-7A62-4601-98DC-4C4791B7158D@dsl-only.net>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 22:17:28 -0000
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 <rdivacky at vlakno.cz> 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: 00000000.001001b0 %SRR1:90000000.00003030
>
> 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
> 0000000000100120 instead; relative
> offsets are unchanged and the code
> is mostly the same.)
>
> Disassembly of section .text:
> 0000000000100160 <.__start> mfmsr r20
> 0000000000100164 <.__start+0x4> li r21,1
> 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010016c <.__start+0xc> mtmsrd r20
> 0000000000100170 <.__start+0x10> isync
> 0000000000100174 <.__start+0x14> nop
> 0000000000100178 <.__start+0x18> b 0000000000100180 <.__start+0x20>
> 000000000010017c <.__start+0x1c> nop
> 0000000000100180 <.__start+0x20> nop
> 0000000000100184 <.__start+0x24> bl 0000000000100190 <.__start+0x30>
> 0000000000100188 <.__start+0x28> .long 0x0
> 000000000010018c <.__start+0x2c> .long 0xf8ce78
> booting xtoolchain based kernel has: 0xfebeb8 above <<<=== note
> 0000000000100190 <.__start+0x30> mflr r2
> 0000000000100194 <.__start+0x34> ld r1,0(r2)
> 0000000000100198 <.__start+0x38> add r2,r1,r2
> 000000000010019c <.__start+0x3c> ld r31,-32768(r2)
> 00000000001001a0 <.__start+0x40> subf r31,r31,r2
> 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=== !!!!!
> booting xtoolchain based kernel has: r1,-32760(r2) above <<<=== !!!!!
> 00000000001001a8 <.__start+0x48> addi r1,r1,16288
> 00000000001001ac <.__start+0x4c> add r1,r1,r31
> 00000000001001b0 <.__start+0x50> std r3,48(r1)
> SRR0 points at the above instruction
> (I stopped comparing to the booting xtoolchain
> based code after this.)
> 00000000001001b4 <.__start+0x54> std r4,56(r1)
> 00000000001001b8 <.__start+0x58> std r5,64(r1)
> 00000000001001bc <.__start+0x5c> std r6,72(r1)
> 00000000001001c0 <.__start+0x60> bl 00000000001001cc <.__start+0x6c>
> 00000000001001c4 <.__start+0x64> .long 0x0
> 00000000001001c8 <.__start+0x68> .long 0xf84ed4
> 00000000001001cc <.__start+0x6c> mflr r3
> 00000000001001d0 <.__start+0x70> ld r4,0(r3)
> 00000000001001d4 <.__start+0x74> add r3,r4,r3
> 00000000001001d8 <.__start+0x78> mr r4,r31
> 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc <.elf_reloc_self>
> 00000000001001e0 <.__start+0x80> nop
> 00000000001001e4 <.__start+0x84> ld r3,48(r1)
> 00000000001001e8 <.__start+0x88> ld r4,56(r1)
> 00000000001001ec <.__start+0x8c> ld r5,64(r1)
> 00000000001001f0 <.__start+0x90> ld r6,72(r1)
> 00000000001001f4 <.__start+0x94> mr r4,r2
> 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 <.powerpc_init>
> 00000000001001fc <.__start+0x9c> nop
> 0000000000100200 <.__start+0xa0> mr r1,r3
> 0000000000100204 <.__start+0xa4> li r3,0
> 0000000000100208 <.__start+0xa8> std r3,0(r1)
> 000000000010020c <.__start+0xac> bl 00000000005c4af8 <.mi_startup>
> 0000000000100210 <.__start+0xb0> nop
> 0000000000100214 <.__start+0xb4> b 0000000000100214 <.__start+0xb4>
>
>
>
> 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: 00000000.00000000 %SRR1:10000000.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:
> 0000000000100160 <.__start-0x2030> std r2,40(r1)
> 0000000000100164 <.__start-0x202c> addis r2,r2,1
> 0000000000100168 <.__start-0x2028> addi r2,r2,-8
> 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 <.cpu_switch>
> 0000000000100170 <.__start-0x2020> std r2,40(r1)
> 0000000000100174 <.__start-0x201c> addis r2,r2,1
> 0000000000100178 <.__start-0x2018> addi r2,r2,-8
> 000000000010017c <.__start-0x2014> b 0000000000ade6c8 <.sf_buf_alloc>
> 0000000000100180 <.__start-0x2010> std r2,40(r1)
> 0000000000100184 <.__start-0x200c> addis r2,r2,1
> 0000000000100188 <.__start-0x2008> addi r2,r2,-8
> 000000000010018c <.__start-0x2004> b 0000000000a83f78 <.vm_fault_hold>
> 0000000000100190 <.__start-0x2000> std r2,40(r1)
> 0000000000100194 <.__start-0x1ffc> addis r2,r2,1
> 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8
> 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 <.fill_regs32>
> 00000000001001a0 <.__start-0x1ff0> std r2,40(r1)
> 00000000001001a4 <.__start-0x1fec> addis r2,r2,1
> 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8
> 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 <.casueword32>
> 00000000001001b0 <.__start-0x1fe0> std r2,40(r1)
> 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1
> 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8
> 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 <.kmap_free_wakeup>
> . . .
> 0000000000102190 <.__start> mfmsr r20
> 0000000000102194 <.__start+0x4> li r21,1
> 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010219c <.__start+0xc> mtmsrd r20
> 00000000001021a0 <.__start+0x10> isync
> 00000000001021a4 <.__start+0x14> nop
> 00000000001021a8 <.__start+0x18> b 00000000001021b0 <.__start+0x20>
> 00000000001021ac <.__start+0x1c> nop
> 00000000001021b0 <.__start+0x20> nop
> 00000000001021b4 <.__start+0x24> bl 00000000001021c0 <.__start+0x30>
> 00000000001021b8 <.__start+0x28> .long 0x0
> 00000000001021bc <.__start+0x2c> .long 0xfc8e48
> 00000000001021c0 <.__start+0x30> mflr r2
> 00000000001021c4 <.__start+0x34> ld r1,0(r2)
> 00000000001021c8 <.__start+0x38> add r2,r1,r2
> 00000000001021cc <.__start+0x3c> ld r31,-32768(r2)
> 00000000001021d0 <.__start+0x40> subf r31,r31,r2
> 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. -32760 oddity!!!
> 00000000001021d8 <.__start+0x48> addi r1,r1,16288
> 00000000001021dc <.__start+0x4c> add r1,r1,r31
> 00000000001021e0 <.__start+0x50> std r3,48(r1)
> 00000000001021e4 <.__start+0x54> std r4,56(r1)
> 00000000001021e8 <.__start+0x58> std r5,64(r1)
> 00000000001021ec <.__start+0x5c> std r6,72(r1)
> 00000000001021f0 <.__start+0x60> bl 00000000001021fc <.__start+0x6c>
> 00000000001021f4 <.__start+0x64> .long 0x0
> 00000000001021f8 <.__start+0x68> .long 0xfd4014
> 00000000001021fc <.__start+0x6c> mflr r3
> 0000000000102200 <.__start+0x70> ld r4,0(r3)
> 0000000000102204 <.__start+0x74> add r3,r4,r3
> 0000000000102208 <.__start+0x78> mr r4,r31
> 000000000010220c <.__start+0x7c> bl 0000000000101a20 <begin+0x1a20>
> 0000000000102210 <.__start+0x80> ld r2,40(r1)
> 0000000000102214 <.__start+0x84> ld r3,48(r1)
> 0000000000102218 <.__start+0x88> ld r4,56(r1)
> 000000000010221c <.__start+0x8c> ld r5,64(r1)
> 0000000000102220 <.__start+0x90> ld r6,72(r1)
> 0000000000102224 <.__start+0x94> mr r4,r2
> 0000000000102228 <.__start+0x98> bl 00000000001019a0 <begin+0x19a0>
> 000000000010222c <.__start+0x9c> ld r2,40(r1)
> 0000000000102230 <.__start+0xa0> mr r1,r3
> 0000000000102234 <.__start+0xa4> li r3,0
> 0000000000102238 <.__start+0xa8> std r3,0(r1)
> 000000000010223c <.__start+0xac> bl 00000000005c6b28 <.mi_startup>
> 0000000000102240 <.__start+0xb0> nop
> 0000000000102244 <.__start+0xb4> b 0000000000102244 <.__start+0xb4>
>
>
> Who is most appropriate to send such information to for powerpc64?
>
> ===
> Mark Millard
> markmi at dsl-only.net
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 23:01:32 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F7FDC6E01F
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Thu, 8 Dec 2016 23:01:32 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net
[208.70.210.72])
(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 D4CF3950
for <freebsd-toolchain@freebsd.org>; Thu, 8 Dec 2016 23:01:31 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 32516 invoked from network); 8 Dec 2016 23:01:30 -0000
Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2)
by 0 (rfx-qmail) with SMTP; 8 Dec 2016 23:01:30 -0000
Received: by mail-cs-02.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Thu, 08 Dec 2016 18:01:37 -0500 (EST)
Received: (qmail 20397 invoked from network); 8 Dec 2016 23:01:37 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 23:01:37 -0000
Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net
[67.170.167.181])
by iron2.pdx.net (Postfix) with ESMTPSA id 260CDEC900F;
Thu, 8 Dec 2016 15:01:29 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <20161208221452.GA42380@vlakno.cz>
Date: Thu, 8 Dec 2016 15:01:28 -0800
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
<D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
<20161207190057.GA58950@vlakno.cz>
<E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net>
<CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net>
<20161208185541.GA33364@vlakno.cz>
<E49F7EE4-7A62-4601-98DC-4C4791B7158D@dsl-only.net>
<20161208221452.GA42380@vlakno.cz>
To: Roman Divacky <rdivacky@vlakno.cz>,
Nathan Whitehorn <nwhitehorn@freebsd.org>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 23:01:32 -0000
On 2016-Dec-8, at 2:14 PM, Roman Divacky <rdivacky@vlakno.cz> wrote:
> I believe the code comes from sys/powerpc/aim/locore64.S and if you =
compare
> the different values from the disssembly with the .S code you can see
> it's __tocbase and TOC_REF().
>=20
> I wonder if the assembly has the -mminimal-toc knowledge hardcoded in =
somehow.
> I am not sure what expectations the locore64.S has about the kernel =
layout that
> we're probably breaking.
>=20
> I've CCed Nathan Whitehorn. Nathan, can you take a look please?
>=20
> Thanks, Roman
For Nathan's reference about the context:
I got to the point of having a clang 3.9.0 buildkernel finish
for targeting powerpc64. But it does not boot.
I'm working from head -r309656 with the following patches:
(ignoring my usual PowerMac G5 powerpc64 booting hack related
materials that I've had in place for a long time)
# svnlite diff /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =
(revision 309656)
+++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working =
copy)
@@ -2300,6 +2300,12 @@
def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
"mftb $RT, $SPR", IIC_SprMFTB>;
=20
+def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
+ "mfpmr $RT, $PMRN", IIC_IntGeneral>;
+
+def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
+ "mtpmr $PMRN, $RS", IIC_IntGeneral>;
+
// A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
// on a 32-bit target.
let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
(Roman Divacky supplied the above patch.)
# svnlite diff /usr/src/sys/modules/zfs/Makefile
Index: /usr/src/sys/modules/zfs/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/sys/modules/zfs/Makefile (revision 309656)
+++ /usr/src/sys/modules/zfs/Makefile (working copy)
@@ -93,9 +93,9 @@
CFLAGS+=3D-I${SUNW}/common
CFLAGS+=3D-DBUILDING_ZFS
=20
-.if ${MACHINE_ARCH} =3D=3D "powerpc64"
-CFLAGS+=3D-mminimal-toc
-.endif
+#.if ${MACHINE_ARCH} =3D=3D "powerpc64"
+#CFLAGS+=3D-mminimal-toc
+#.endif
=20
.ifdef ZFS_DEBUG
CFLAGS+=3D-DDEBUG=3D1
This last just avoids that clang 3.9.0 for targeting
powerpc64 rejects the -mminimal-toc command line option.
It being missing did not cause the buildkernel to stop.
Note: I have booted with clang 3.9.0 based buildworld
materials. (But C++ exception handling is still messed
up so code dependent on C++ exceptions happening needs
to be avoided.) I've had to avoid both
WITH_BINUTILS_BOOTSTRAP=3D like binutils and 2.47 variants
of devel/powerpc64-binutils or devel/binutils: I use
older 2.25.1 devel/powerpc64-binutils or devel/binutils
(on the powerpc64 itself).
However for buildkernel WITH_BINUTILS_BOOTSTRAP=3D like
binutils do not end up with ld failing and buildkernel
appears to complete.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Older material:
On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote:
> [I have dropped the patch related information and just have
> failing-boot related information here.]
>=20
> On 2016-Dec-8, at 10:55 AM, Roman Divacky <rdivacky at vlakno.cz> =
wrote:
>=20
>> Can you try to investigate why it dies? I am not convinced =
-mminimal-toc
>> would result in a boot failure. I think the kernel would fail to =
link.
>=20
> I give information for both devel/powerpc64-binutils based
> and for WITH_BINUTILS_BOOTSTRAP=3D based. They are different.
>=20
> For using 2.25.1 of devel/powerpc64-binutils (a cross build):
> (from camera image of screen)
>=20
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker390
> /boot/ker390/kernel data=3D0xf851a8+0x42dd98 =
syms=3D[0x8+0xd6848+0x8+0xf1137]
> /boot/entropy size=3D0x1000
> Booting. . .
> Kernel entry at 0x100160
>=20
> Invalid memory access at %SSR0: 00000000.001001b0 =
%SRR1:90000000.00003030
>=20
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
>=20
> The only options at this point are:
>=20
> mac-boot
> shut-down
>=20
>=20
> =46rom objdump for the above failing boot
> but with notes added:
> (Note: booting xtoolchain kernel starts at
> 0000000000100120 instead; relative
> offsets are unchanged and the code
> is mostly the same.)
>=20
> Disassembly of section .text:
> 0000000000100160 <.__start> mfmsr r20
> 0000000000100164 <.__start+0x4> li r21,1
> 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010016c <.__start+0xc> mtmsrd r20
> 0000000000100170 <.__start+0x10> isync
> 0000000000100174 <.__start+0x14> nop
> 0000000000100178 <.__start+0x18> b 0000000000100180 =
<.__start+0x20>
> 000000000010017c <.__start+0x1c> nop
> 0000000000100180 <.__start+0x20> nop
> 0000000000100184 <.__start+0x24> bl 0000000000100190 =
<.__start+0x30>
> 0000000000100188 <.__start+0x28> .long 0x0
> 000000000010018c <.__start+0x2c> .long 0xf8ce78 =20
> booting xtoolchain based kernel has: 0xfebeb8 above <<<=3D=3D=3D =
note
> 0000000000100190 <.__start+0x30> mflr r2
> 0000000000100194 <.__start+0x34> ld r1,0(r2)
> 0000000000100198 <.__start+0x38> add r2,r1,r2
> 000000000010019c <.__start+0x3c> ld r31,-32768(r2)
> 00000000001001a0 <.__start+0x40> subf r31,r31,r2
> 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D=
!!!!!
> booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D=
!!!!!
> 00000000001001a8 <.__start+0x48> addi r1,r1,16288
> 00000000001001ac <.__start+0x4c> add r1,r1,r31
> 00000000001001b0 <.__start+0x50> std r3,48(r1)
> SRR0 points at the above instruction
> (I stopped comparing to the booting xtoolchain
> based code after this.)
> 00000000001001b4 <.__start+0x54> std r4,56(r1)
> 00000000001001b8 <.__start+0x58> std r5,64(r1)
> 00000000001001bc <.__start+0x5c> std r6,72(r1)
> 00000000001001c0 <.__start+0x60> bl 00000000001001cc =
<.__start+0x6c>
> 00000000001001c4 <.__start+0x64> .long 0x0
> 00000000001001c8 <.__start+0x68> .long 0xf84ed4
> 00000000001001cc <.__start+0x6c> mflr r3
> 00000000001001d0 <.__start+0x70> ld r4,0(r3)
> 00000000001001d4 <.__start+0x74> add r3,r4,r3
> 00000000001001d8 <.__start+0x78> mr r4,r31
> 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc =
<.elf_reloc_self>
> 00000000001001e0 <.__start+0x80> nop
> 00000000001001e4 <.__start+0x84> ld r3,48(r1)
> 00000000001001e8 <.__start+0x88> ld r4,56(r1)
> 00000000001001ec <.__start+0x8c> ld r5,64(r1)
> 00000000001001f0 <.__start+0x90> ld r6,72(r1)
> 00000000001001f4 <.__start+0x94> mr r4,r2
> 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 =
<.powerpc_init>
> 00000000001001fc <.__start+0x9c> nop
> 0000000000100200 <.__start+0xa0> mr r1,r3
> 0000000000100204 <.__start+0xa4> li r3,0
> 0000000000100208 <.__start+0xa8> std r3,0(r1)
> 000000000010020c <.__start+0xac> bl 00000000005c4af8 =
<.mi_startup>
> 0000000000100210 <.__start+0xb0> nop
> 0000000000100214 <.__start+0xb4> b 0000000000100214 =
<.__start+0xb4>
>=20
>=20
>=20
> For using WITH_BINUTILS_BOOTSTRAP=3D based binutils (a cross build):
> (completes for buildkernel; fails for buildworld)
>=20
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker39a
> /boot/ker39a/kernel data=3D0xfd6318+0x42dda8 =
syms=3D[0x8+0xd6860+0x8+0xf1193]
> /boot/entropy size=3D0x1000
> Booting. . .
> Kernel entry at 0x100160
>=20
> Invalid memory access at %SSR0: 00000000.00000000 =
%SRR1:10000000.00081000
>=20
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
>=20
> The only options at this point are:
>=20
> mac-boot
> shut-down
>=20
> The problem here is a different code order and a matching
> wrong start address that does not track the difference.
> (=46rom objdump.) Note: the same 0(r2) vs. -32760(r2) oddity
> exists in the start routine as well.
>=20
> Disassembly of section .text:
> 0000000000100160 <.__start-0x2030> std r2,40(r1)
> 0000000000100164 <.__start-0x202c> addis r2,r2,1
> 0000000000100168 <.__start-0x2028> addi r2,r2,-8
> 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 =
<.cpu_switch>
> 0000000000100170 <.__start-0x2020> std r2,40(r1)
> 0000000000100174 <.__start-0x201c> addis r2,r2,1
> 0000000000100178 <.__start-0x2018> addi r2,r2,-8
> 000000000010017c <.__start-0x2014> b 0000000000ade6c8 =
<.sf_buf_alloc>
> 0000000000100180 <.__start-0x2010> std r2,40(r1)
> 0000000000100184 <.__start-0x200c> addis r2,r2,1
> 0000000000100188 <.__start-0x2008> addi r2,r2,-8
> 000000000010018c <.__start-0x2004> b 0000000000a83f78 =
<.vm_fault_hold>
> 0000000000100190 <.__start-0x2000> std r2,40(r1)
> 0000000000100194 <.__start-0x1ffc> addis r2,r2,1
> 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8
> 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 =
<.fill_regs32>
> 00000000001001a0 <.__start-0x1ff0> std r2,40(r1)
> 00000000001001a4 <.__start-0x1fec> addis r2,r2,1
> 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8
> 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 =
<.casueword32>
> 00000000001001b0 <.__start-0x1fe0> std r2,40(r1)
> 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1
> 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8
> 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 =
<.kmap_free_wakeup>
> . . .
> 0000000000102190 <.__start> mfmsr r20
> 0000000000102194 <.__start+0x4> li r21,1
> 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010219c <.__start+0xc> mtmsrd r20
> 00000000001021a0 <.__start+0x10> isync
> 00000000001021a4 <.__start+0x14> nop
> 00000000001021a8 <.__start+0x18> b 00000000001021b0 =
<.__start+0x20>
> 00000000001021ac <.__start+0x1c> nop
> 00000000001021b0 <.__start+0x20> nop
> 00000000001021b4 <.__start+0x24> bl 00000000001021c0 =
<.__start+0x30>
> 00000000001021b8 <.__start+0x28> .long 0x0
> 00000000001021bc <.__start+0x2c> .long 0xfc8e48
> 00000000001021c0 <.__start+0x30> mflr r2
> 00000000001021c4 <.__start+0x34> ld r1,0(r2)
> 00000000001021c8 <.__start+0x38> add r2,r1,r2
> 00000000001021cc <.__start+0x3c> ld r31,-32768(r2)
> 00000000001021d0 <.__start+0x40> subf r31,r31,r2
> 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. =
-32760 oddity!!!
> 00000000001021d8 <.__start+0x48> addi r1,r1,16288
> 00000000001021dc <.__start+0x4c> add r1,r1,r31
> 00000000001021e0 <.__start+0x50> std r3,48(r1)
> 00000000001021e4 <.__start+0x54> std r4,56(r1)
> 00000000001021e8 <.__start+0x58> std r5,64(r1)
> 00000000001021ec <.__start+0x5c> std r6,72(r1)
> 00000000001021f0 <.__start+0x60> bl 00000000001021fc =
<.__start+0x6c>
> 00000000001021f4 <.__start+0x64> .long 0x0
> 00000000001021f8 <.__start+0x68> .long 0xfd4014
> 00000000001021fc <.__start+0x6c> mflr r3
> 0000000000102200 <.__start+0x70> ld r4,0(r3)
> 0000000000102204 <.__start+0x74> add r3,r4,r3
> 0000000000102208 <.__start+0x78> mr r4,r31
> 000000000010220c <.__start+0x7c> bl 0000000000101a20 =
<begin+0x1a20>
> 0000000000102210 <.__start+0x80> ld r2,40(r1)
> 0000000000102214 <.__start+0x84> ld r3,48(r1)
> 0000000000102218 <.__start+0x88> ld r4,56(r1)
> 000000000010221c <.__start+0x8c> ld r5,64(r1)
> 0000000000102220 <.__start+0x90> ld r6,72(r1)
> 0000000000102224 <.__start+0x94> mr r4,r2
> 0000000000102228 <.__start+0x98> bl 00000000001019a0 =
<begin+0x19a0>
> 000000000010222c <.__start+0x9c> ld r2,40(r1)
> 0000000000102230 <.__start+0xa0> mr r1,r3
> 0000000000102234 <.__start+0xa4> li r3,0
> 0000000000102238 <.__start+0xa8> std r3,0(r1)
> 000000000010223c <.__start+0xac> bl 00000000005c6b28 =
<.mi_startup>
> 0000000000102240 <.__start+0xb0> nop
> 0000000000102244 <.__start+0xb4> b 0000000000102244 =
<.__start+0xb4>
>=20
>=20
> Who is most appropriate to send such information to for powerpc64?
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
From owner-freebsd-toolchain@freebsd.org Thu Dec 8 23:26:45 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4FB7C6E74A
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Thu, 8 Dec 2016 23:26:45 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net
[208.70.210.72])
(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 700311377
for <freebsd-toolchain@freebsd.org>; Thu, 8 Dec 2016 23:26:44 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 12798 invoked from network); 8 Dec 2016 23:27:35 -0000
Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1)
by 0 (rfx-qmail) with SMTP; 8 Dec 2016 23:27:35 -0000
Received: by mail-cs-01.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Thu, 08 Dec 2016 18:26:55 -0500 (EST)
Received: (qmail 10503 invoked from network); 8 Dec 2016 23:26:55 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 23:26:55 -0000
Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net
[67.170.167.181])
by iron2.pdx.net (Postfix) with ESMTPSA id F0921EC7B35;
Thu, 8 Dec 2016 15:26:42 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net>
Date: Thu, 8 Dec 2016 15:26:42 -0800
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <20480337-3CF7-4ED4-AB55-ADE18A3F0F75@dsl-only.net>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
<D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
<20161207190057.GA58950@vlakno.cz>
<E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net>
<CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net>
<20161208185541.GA33364@vlakno.cz>
<E49F7EE4-7A62-4601-98DC-4C4791B7158D@dsl-only.net>
<20161208221452.GA42380@vlakno.cz>
<29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net>
To: Roman Divacky <rdivacky@vlakno.cz>,
Nathan Whitehorn <nwhitehorn@freebsd.org>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 23:26:45 -0000
[Top post noting a systematic stupid typo of mine.]
I keep typing 2.47 instead of 2.27 for devel/binutils
and devel/powerpc64-binutils .
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Dec-8, at 3:01 PM, Mark Millard <markmi@dsl-only.net> wrote:
On 2016-Dec-8, at 2:14 PM, Roman Divacky <rdivacky@vlakno.cz> wrote:
> I believe the code comes from sys/powerpc/aim/locore64.S and if you =
compare
> the different values from the disssembly with the .S code you can see
> it's __tocbase and TOC_REF().
>=20
> I wonder if the assembly has the -mminimal-toc knowledge hardcoded in =
somehow.
> I am not sure what expectations the locore64.S has about the kernel =
layout that
> we're probably breaking.
>=20
> I've CCed Nathan Whitehorn. Nathan, can you take a look please?
>=20
> Thanks, Roman
For Nathan's reference about the context:
I got to the point of having a clang 3.9.0 buildkernel finish
for targeting powerpc64. But it does not boot.
I'm working from head -r309656 with the following patches:
(ignoring my usual PowerMac G5 powerpc64 booting hack related
materials that I've had in place for a long time)
# svnlite diff /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =
(revision 309656)
+++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working =
copy)
@@ -2300,6 +2300,12 @@
def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
"mftb $RT, $SPR", IIC_SprMFTB>;
+def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
+ "mfpmr $RT, $PMRN", IIC_IntGeneral>;
+
+def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
+ "mtpmr $PMRN, $RS", IIC_IntGeneral>;
+
// A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
// on a 32-bit target.
let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
(Roman Divacky supplied the above patch.)
# svnlite diff /usr/src/sys/modules/zfs/Makefile
Index: /usr/src/sys/modules/zfs/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/sys/modules/zfs/Makefile (revision 309656)
+++ /usr/src/sys/modules/zfs/Makefile (working copy)
@@ -93,9 +93,9 @@
CFLAGS+=3D-I${SUNW}/common
CFLAGS+=3D-DBUILDING_ZFS
-.if ${MACHINE_ARCH} =3D=3D "powerpc64"
-CFLAGS+=3D-mminimal-toc
-.endif
+#.if ${MACHINE_ARCH} =3D=3D "powerpc64"
+#CFLAGS+=3D-mminimal-toc
+#.endif
.ifdef ZFS_DEBUG
CFLAGS+=3D-DDEBUG=3D1
This last just avoids that clang 3.9.0 for targeting
powerpc64 rejects the -mminimal-toc command line option.
It being missing did not cause the buildkernel to stop.
Note: I have booted with clang 3.9.0 based buildworld
materials. (But C++ exception handling is still messed
up so code dependent on C++ exceptions happening needs
to be avoided.) I've had to avoid both
WITH_BINUTILS_BOOTSTRAP=3D like binutils and 2.47 variants
of devel/powerpc64-binutils or devel/binutils: I use
older 2.25.1 devel/powerpc64-binutils or devel/binutils
(on the powerpc64 itself).
However for buildkernel WITH_BINUTILS_BOOTSTRAP=3D like
binutils do not end up with ld failing and buildkernel
appears to complete.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Older material:
On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote:
> [I have dropped the patch related information and just have
> failing-boot related information here.]
>=20
> On 2016-Dec-8, at 10:55 AM, Roman Divacky <rdivacky at vlakno.cz> =
wrote:
>=20
>> Can you try to investigate why it dies? I am not convinced =
-mminimal-toc
>> would result in a boot failure. I think the kernel would fail to =
link.
>=20
> I give information for both devel/powerpc64-binutils based
> and for WITH_BINUTILS_BOOTSTRAP=3D based. They are different.
>=20
> For using 2.25.1 of devel/powerpc64-binutils (a cross build):
> (from camera image of screen)
>=20
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker390
> /boot/ker390/kernel data=3D0xf851a8+0x42dd98 =
syms=3D[0x8+0xd6848+0x8+0xf1137]
> /boot/entropy size=3D0x1000
> Booting. . .
> Kernel entry at 0x100160
>=20
> Invalid memory access at %SSR0: 00000000.001001b0 =
%SRR1:90000000.00003030
>=20
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
>=20
> The only options at this point are:
>=20
> mac-boot
> shut-down
>=20
>=20
> =46rom objdump for the above failing boot
> but with notes added:
> (Note: booting xtoolchain kernel starts at
> 0000000000100120 instead; relative
> offsets are unchanged and the code
> is mostly the same.)
>=20
> Disassembly of section .text:
> 0000000000100160 <.__start> mfmsr r20
> 0000000000100164 <.__start+0x4> li r21,1
> 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010016c <.__start+0xc> mtmsrd r20
> 0000000000100170 <.__start+0x10> isync
> 0000000000100174 <.__start+0x14> nop
> 0000000000100178 <.__start+0x18> b 0000000000100180 =
<.__start+0x20>
> 000000000010017c <.__start+0x1c> nop
> 0000000000100180 <.__start+0x20> nop
> 0000000000100184 <.__start+0x24> bl 0000000000100190 =
<.__start+0x30>
> 0000000000100188 <.__start+0x28> .long 0x0
> 000000000010018c <.__start+0x2c> .long 0xf8ce78 =20
> booting xtoolchain based kernel has: 0xfebeb8 above <<<=3D=3D=3D =
note
> 0000000000100190 <.__start+0x30> mflr r2
> 0000000000100194 <.__start+0x34> ld r1,0(r2)
> 0000000000100198 <.__start+0x38> add r2,r1,r2
> 000000000010019c <.__start+0x3c> ld r31,-32768(r2)
> 00000000001001a0 <.__start+0x40> subf r31,r31,r2
> 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D=
!!!!!
> booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D =
!!!!!
> 00000000001001a8 <.__start+0x48> addi r1,r1,16288
> 00000000001001ac <.__start+0x4c> add r1,r1,r31
> 00000000001001b0 <.__start+0x50> std r3,48(r1)
> SRR0 points at the above instruction
> (I stopped comparing to the booting xtoolchain
> based code after this.)
> 00000000001001b4 <.__start+0x54> std r4,56(r1)
> 00000000001001b8 <.__start+0x58> std r5,64(r1)
> 00000000001001bc <.__start+0x5c> std r6,72(r1)
> 00000000001001c0 <.__start+0x60> bl 00000000001001cc =
<.__start+0x6c>
> 00000000001001c4 <.__start+0x64> .long 0x0
> 00000000001001c8 <.__start+0x68> .long 0xf84ed4
> 00000000001001cc <.__start+0x6c> mflr r3
> 00000000001001d0 <.__start+0x70> ld r4,0(r3)
> 00000000001001d4 <.__start+0x74> add r3,r4,r3
> 00000000001001d8 <.__start+0x78> mr r4,r31
> 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc =
<.elf_reloc_self>
> 00000000001001e0 <.__start+0x80> nop
> 00000000001001e4 <.__start+0x84> ld r3,48(r1)
> 00000000001001e8 <.__start+0x88> ld r4,56(r1)
> 00000000001001ec <.__start+0x8c> ld r5,64(r1)
> 00000000001001f0 <.__start+0x90> ld r6,72(r1)
> 00000000001001f4 <.__start+0x94> mr r4,r2
> 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 =
<.powerpc_init>
> 00000000001001fc <.__start+0x9c> nop
> 0000000000100200 <.__start+0xa0> mr r1,r3
> 0000000000100204 <.__start+0xa4> li r3,0
> 0000000000100208 <.__start+0xa8> std r3,0(r1)
> 000000000010020c <.__start+0xac> bl 00000000005c4af8 =
<.mi_startup>
> 0000000000100210 <.__start+0xb0> nop
> 0000000000100214 <.__start+0xb4> b 0000000000100214 =
<.__start+0xb4>
>=20
>=20
>=20
> For using WITH_BINUTILS_BOOTSTRAP=3D based binutils (a cross build):
> (completes for buildkernel; fails for buildworld)
>=20
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker39a
> /boot/ker39a/kernel data=3D0xfd6318+0x42dda8 =
syms=3D[0x8+0xd6860+0x8+0xf1193]
> /boot/entropy size=3D0x1000
> Booting. . .
> Kernel entry at 0x100160
>=20
> Invalid memory access at %SSR0: 00000000.00000000 =
%SRR1:10000000.00081000
>=20
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
>=20
> The only options at this point are:
>=20
> mac-boot
> shut-down
>=20
> The problem here is a different code order and a matching
> wrong start address that does not track the difference.
> (=46rom objdump.) Note: the same 0(r2) vs. -32760(r2) oddity
> exists in the start routine as well.
>=20
> Disassembly of section .text:
> 0000000000100160 <.__start-0x2030> std r2,40(r1)
> 0000000000100164 <.__start-0x202c> addis r2,r2,1
> 0000000000100168 <.__start-0x2028> addi r2,r2,-8
> 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 =
<.cpu_switch>
> 0000000000100170 <.__start-0x2020> std r2,40(r1)
> 0000000000100174 <.__start-0x201c> addis r2,r2,1
> 0000000000100178 <.__start-0x2018> addi r2,r2,-8
> 000000000010017c <.__start-0x2014> b 0000000000ade6c8 =
<.sf_buf_alloc>
> 0000000000100180 <.__start-0x2010> std r2,40(r1)
> 0000000000100184 <.__start-0x200c> addis r2,r2,1
> 0000000000100188 <.__start-0x2008> addi r2,r2,-8
> 000000000010018c <.__start-0x2004> b 0000000000a83f78 =
<.vm_fault_hold>
> 0000000000100190 <.__start-0x2000> std r2,40(r1)
> 0000000000100194 <.__start-0x1ffc> addis r2,r2,1
> 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8
> 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 =
<.fill_regs32>
> 00000000001001a0 <.__start-0x1ff0> std r2,40(r1)
> 00000000001001a4 <.__start-0x1fec> addis r2,r2,1
> 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8
> 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 =
<.casueword32>
> 00000000001001b0 <.__start-0x1fe0> std r2,40(r1)
> 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1
> 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8
> 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 =
<.kmap_free_wakeup>
> . . .
> 0000000000102190 <.__start> mfmsr r20
> 0000000000102194 <.__start+0x4> li r21,1
> 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010219c <.__start+0xc> mtmsrd r20
> 00000000001021a0 <.__start+0x10> isync
> 00000000001021a4 <.__start+0x14> nop
> 00000000001021a8 <.__start+0x18> b 00000000001021b0 =
<.__start+0x20>
> 00000000001021ac <.__start+0x1c> nop
> 00000000001021b0 <.__start+0x20> nop
> 00000000001021b4 <.__start+0x24> bl 00000000001021c0 =
<.__start+0x30>
> 00000000001021b8 <.__start+0x28> .long 0x0
> 00000000001021bc <.__start+0x2c> .long 0xfc8e48
> 00000000001021c0 <.__start+0x30> mflr r2
> 00000000001021c4 <.__start+0x34> ld r1,0(r2)
> 00000000001021c8 <.__start+0x38> add r2,r1,r2
> 00000000001021cc <.__start+0x3c> ld r31,-32768(r2)
> 00000000001021d0 <.__start+0x40> subf r31,r31,r2
> 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. =
-32760 oddity!!!
> 00000000001021d8 <.__start+0x48> addi r1,r1,16288
> 00000000001021dc <.__start+0x4c> add r1,r1,r31
> 00000000001021e0 <.__start+0x50> std r3,48(r1)
> 00000000001021e4 <.__start+0x54> std r4,56(r1)
> 00000000001021e8 <.__start+0x58> std r5,64(r1)
> 00000000001021ec <.__start+0x5c> std r6,72(r1)
> 00000000001021f0 <.__start+0x60> bl 00000000001021fc =
<.__start+0x6c>
> 00000000001021f4 <.__start+0x64> .long 0x0
> 00000000001021f8 <.__start+0x68> .long 0xfd4014
> 00000000001021fc <.__start+0x6c> mflr r3
> 0000000000102200 <.__start+0x70> ld r4,0(r3)
> 0000000000102204 <.__start+0x74> add r3,r4,r3
> 0000000000102208 <.__start+0x78> mr r4,r31
> 000000000010220c <.__start+0x7c> bl 0000000000101a20 =
<begin+0x1a20>
> 0000000000102210 <.__start+0x80> ld r2,40(r1)
> 0000000000102214 <.__start+0x84> ld r3,48(r1)
> 0000000000102218 <.__start+0x88> ld r4,56(r1)
> 000000000010221c <.__start+0x8c> ld r5,64(r1)
> 0000000000102220 <.__start+0x90> ld r6,72(r1)
> 0000000000102224 <.__start+0x94> mr r4,r2
> 0000000000102228 <.__start+0x98> bl 00000000001019a0 =
<begin+0x19a0>
> 000000000010222c <.__start+0x9c> ld r2,40(r1)
> 0000000000102230 <.__start+0xa0> mr r1,r3
> 0000000000102234 <.__start+0xa4> li r3,0
> 0000000000102238 <.__start+0xa8> std r3,0(r1)
> 000000000010223c <.__start+0xac> bl 00000000005c6b28 =
<.mi_startup>
> 0000000000102240 <.__start+0xb0> nop
> 0000000000102244 <.__start+0xb4> b 0000000000102244 =
<.__start+0xb4>
>=20
>=20
> Who is most appropriate to send such information to for powerpc64?
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to =
"freebsd-toolchain-unsubscribe@freebsd.org"
From owner-freebsd-toolchain@freebsd.org Fri Dec 9 02:13:53 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9007C6D2DE
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Fri, 9 Dec 2016 02:13:53 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 B7D831A80
for <freebsd-toolchain@FreeBSD.org>; Fri, 9 Dec 2016 02:13:53 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB92Dr36092363
for <freebsd-toolchain@FreeBSD.org>; Fri, 9 Dec 2016 02:13:53 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64
cross-built buildkernel stops for: rejected assembler notation
Date: Fri, 09 Dec 2016 02:13:53 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: markmi@dsl-only.net
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-214904-29464-9mxVcQZZsA@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-214904-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-214904-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 02:13:53 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904
--- Comment #2 from Mark Millard <markmi@dsl-only.net> ---
Created attachment 177812
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D177812&action=
=3Dedit
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.)
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Fri Dec 9 02:20:59 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49A00C6D3B4
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Fri, 9 Dec 2016 02:20:59 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 389051C83
for <freebsd-toolchain@FreeBSD.org>; Fri, 9 Dec 2016 02:20:59 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB92KxBj024252
for <freebsd-toolchain@FreeBSD.org>; Fri, 9 Dec 2016 02:20:59 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64
buildkernel stops for: rejected assembler notation in hwpmc_e500.c
Date: Fri, 09 Dec 2016 02:20:59 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: markmi@dsl-only.net
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: short_desc
Message-ID: <bug-214904-29464-h85zE6peOd@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-214904-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-214904-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 02:20:59 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904
Mark Millard <markmi@dsl-only.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|head -r309179 clang 3.9.0 |head -r309179 clang 3.9.0
|TARGET_ARCH=3Dpowerpc64 |TARGET_ARCH=3Dpowerpc64
|cross-built buildkernel |buildkernel stops for:
|stops for: rejected |rejected assembler notation
|assembler notation |in hwpmc_e500.c
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Fri Dec 9 02:47:37 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C71FC6DE6B
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Fri, 9 Dec 2016 02:47:37 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-73.reflexion.net
[208.70.210.73])
(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 00ECEC3F
for <freebsd-toolchain@freebsd.org>; Fri, 9 Dec 2016 02:47:36 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 14966 invoked from network); 9 Dec 2016 02:47:35 -0000
Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1)
by 0 (rfx-qmail) with SMTP; 9 Dec 2016 02:47:35 -0000
Received: by mail-cs-01.app.dca.reflexion.local
(Reflexion email security v8.20.0) with SMTP;
Thu, 08 Dec 2016 21:47:46 -0500 (EST)
Received: (qmail 2269 invoked from network); 9 Dec 2016 02:47:46 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Dec 2016 02:47:46 -0000
Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net
[67.170.167.181])
by iron2.pdx.net (Postfix) with ESMTPSA id 7531FEC9156;
Thu, 8 Dec 2016 18:47:34 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build
hwpmc_e500.o and the like. . .
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <20480337-3CF7-4ED4-AB55-ADE18A3F0F75@dsl-only.net>
Date: Thu, 8 Dec 2016 18:47:33 -0800
Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>,
FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EC1505A-962E-4679-AB5E-021ED352A284@dsl-only.net>
References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net>
<20161205161904.GA7889@vlakno.cz>
<126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net>
<D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net>
<D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net>
<20161207190057.GA58950@vlakno.cz>
<E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net>
<CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net>
<20161208185541.GA33364@vlakno.cz>
<E49F7EE4-7A62-4601-98DC-4C4791B7158D@dsl-only.net>
<20161208221452.GA42380@vlakno.cz>
<29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net>
<20480337-3CF7-4ED4-AB55-ADE18A3F0F75@dsl-only.net>
To: Roman Divacky <rdivacky@vlakno.cz>,
Nathan Whitehorn <nwhitehorn@freebsd.org>
X-Mailer: Apple Mail (2.3251)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 02:47:37 -0000
A context point that I forgot to mention. . .
I had to use WERROR=3D 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]
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Dec-8, at 3:26 PM, Mark Millard <markmi at dsl-only.net> 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 .
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Dec-8, at 3:01 PM, Mark Millard <markmi@dsl-only.net> wrote:
On 2016-Dec-8, at 2:14 PM, Roman Divacky <rdivacky@vlakno.cz> wrote:
> I believe the code comes from sys/powerpc/aim/locore64.S and if you =
compare
> the different values from the disssembly with the .S code you can see
> it's __tocbase and TOC_REF().
>=20
> I wonder if the assembly has the -mminimal-toc knowledge hardcoded in =
somehow.
> I am not sure what expectations the locore64.S has about the kernel =
layout that
> we're probably breaking.
>=20
> I've CCed Nathan Whitehorn. Nathan, can you take a look please?
>=20
> Thanks, Roman
For Nathan's reference about the context:
I got to the point of having a clang 3.9.0 buildkernel finish
for targeting powerpc64. But it does not boot.
I'm working from head -r309656 with the following patches:
(ignoring my usual PowerMac G5 powerpc64 booting hack related
materials that I've had in place for a long time)
# svnlite diff /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =
(revision 309656)
+++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working =
copy)
@@ -2300,6 +2300,12 @@
def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
"mftb $RT, $SPR", IIC_SprMFTB>;
+def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
+ "mfpmr $RT, $PMRN", IIC_IntGeneral>;
+
+def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
+ "mtpmr $PMRN, $RS", IIC_IntGeneral>;
+
// A pseudo-instruction used to implement the read of the 64-bit cycle =
counter
// on a 32-bit target.
let hasSideEffects =3D 1, usesCustomInserter =3D 1 in
(Roman Divacky supplied the above patch.)
# svnlite diff /usr/src/sys/modules/zfs/Makefile
Index: /usr/src/sys/modules/zfs/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/sys/modules/zfs/Makefile (revision 309656)
+++ /usr/src/sys/modules/zfs/Makefile (working copy)
@@ -93,9 +93,9 @@
CFLAGS+=3D-I${SUNW}/common
CFLAGS+=3D-DBUILDING_ZFS
-.if ${MACHINE_ARCH} =3D=3D "powerpc64"
-CFLAGS+=3D-mminimal-toc
-.endif
+#.if ${MACHINE_ARCH} =3D=3D "powerpc64"
+#CFLAGS+=3D-mminimal-toc
+#.endif
.ifdef ZFS_DEBUG
CFLAGS+=3D-DDEBUG=3D1
This last just avoids that clang 3.9.0 for targeting
powerpc64 rejects the -mminimal-toc command line option.
It being missing did not cause the buildkernel to stop.
Note: I have booted with clang 3.9.0 based buildworld
materials. (But C++ exception handling is still messed
up so code dependent on C++ exceptions happening needs
to be avoided.) I've had to avoid both
WITH_BINUTILS_BOOTSTRAP=3D like binutils and 2.47 variants
of devel/powerpc64-binutils or devel/binutils: I use
older 2.25.1 devel/powerpc64-binutils or devel/binutils
(on the powerpc64 itself).
However for buildkernel WITH_BINUTILS_BOOTSTRAP=3D like
binutils do not end up with ld failing and buildkernel
appears to complete.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Older material:
On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote:
> [I have dropped the patch related information and just have
> failing-boot related information here.]
>=20
> On 2016-Dec-8, at 10:55 AM, Roman Divacky <rdivacky at vlakno.cz> =
wrote:
>=20
>> Can you try to investigate why it dies? I am not convinced =
-mminimal-toc
>> would result in a boot failure. I think the kernel would fail to =
link.
>=20
> I give information for both devel/powerpc64-binutils based
> and for WITH_BINUTILS_BOOTSTRAP=3D based. They are different.
>=20
> For using 2.25.1 of devel/powerpc64-binutils (a cross build):
> (from camera image of screen)
>=20
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker390
> /boot/ker390/kernel data=3D0xf851a8+0x42dd98 =
syms=3D[0x8+0xd6848+0x8+0xf1137]
> /boot/entropy size=3D0x1000
> Booting. . .
> Kernel entry at 0x100160
>=20
> Invalid memory access at %SSR0: 00000000.001001b0 =
%SRR1:90000000.00003030
>=20
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
>=20
> The only options at this point are:
>=20
> mac-boot
> shut-down
>=20
>=20
> =46rom objdump for the above failing boot
> but with notes added:
> (Note: booting xtoolchain kernel starts at
> 0000000000100120 instead; relative
> offsets are unchanged and the code
> is mostly the same.)
>=20
> Disassembly of section .text:
> 0000000000100160 <.__start> mfmsr r20
> 0000000000100164 <.__start+0x4> li r21,1
> 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010016c <.__start+0xc> mtmsrd r20
> 0000000000100170 <.__start+0x10> isync
> 0000000000100174 <.__start+0x14> nop
> 0000000000100178 <.__start+0x18> b 0000000000100180 =
<.__start+0x20>
> 000000000010017c <.__start+0x1c> nop
> 0000000000100180 <.__start+0x20> nop
> 0000000000100184 <.__start+0x24> bl 0000000000100190 =
<.__start+0x30>
> 0000000000100188 <.__start+0x28> .long 0x0
> 000000000010018c <.__start+0x2c> .long 0xf8ce78 =20
> booting xtoolchain based kernel has: 0xfebeb8 above <<<=3D=3D=3D =
note
> 0000000000100190 <.__start+0x30> mflr r2
> 0000000000100194 <.__start+0x34> ld r1,0(r2)
> 0000000000100198 <.__start+0x38> add r2,r1,r2
> 000000000010019c <.__start+0x3c> ld r31,-32768(r2)
> 00000000001001a0 <.__start+0x40> subf r31,r31,r2
> 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D=
!!!!!
> booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D =
!!!!!
> 00000000001001a8 <.__start+0x48> addi r1,r1,16288
> 00000000001001ac <.__start+0x4c> add r1,r1,r31
> 00000000001001b0 <.__start+0x50> std r3,48(r1)
> SRR0 points at the above instruction
> (I stopped comparing to the booting xtoolchain
> based code after this.)
> 00000000001001b4 <.__start+0x54> std r4,56(r1)
> 00000000001001b8 <.__start+0x58> std r5,64(r1)
> 00000000001001bc <.__start+0x5c> std r6,72(r1)
> 00000000001001c0 <.__start+0x60> bl 00000000001001cc =
<.__start+0x6c>
> 00000000001001c4 <.__start+0x64> .long 0x0
> 00000000001001c8 <.__start+0x68> .long 0xf84ed4
> 00000000001001cc <.__start+0x6c> mflr r3
> 00000000001001d0 <.__start+0x70> ld r4,0(r3)
> 00000000001001d4 <.__start+0x74> add r3,r4,r3
> 00000000001001d8 <.__start+0x78> mr r4,r31
> 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc =
<.elf_reloc_self>
> 00000000001001e0 <.__start+0x80> nop
> 00000000001001e4 <.__start+0x84> ld r3,48(r1)
> 00000000001001e8 <.__start+0x88> ld r4,56(r1)
> 00000000001001ec <.__start+0x8c> ld r5,64(r1)
> 00000000001001f0 <.__start+0x90> ld r6,72(r1)
> 00000000001001f4 <.__start+0x94> mr r4,r2
> 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 =
<.powerpc_init>
> 00000000001001fc <.__start+0x9c> nop
> 0000000000100200 <.__start+0xa0> mr r1,r3
> 0000000000100204 <.__start+0xa4> li r3,0
> 0000000000100208 <.__start+0xa8> std r3,0(r1)
> 000000000010020c <.__start+0xac> bl 00000000005c4af8 =
<.mi_startup>
> 0000000000100210 <.__start+0xb0> nop
> 0000000000100214 <.__start+0xb4> b 0000000000100214 =
<.__start+0xb4>
>=20
>=20
>=20
> For using WITH_BINUTILS_BOOTSTRAP=3D based binutils (a cross build):
> (completes for buildkernel; fails for buildworld)
>=20
> . . . (omitted material) . . .
> Type '?' for a list of commands, 'help' for more detailed help.
> OK unload
> OK boot ker39a
> /boot/ker39a/kernel data=3D0xfd6318+0x42dda8 =
syms=3D[0x8+0xd6860+0x8+0xf1193]
> /boot/entropy size=3D0x1000
> Booting. . .
> Kernel entry at 0x100160
>=20
> Invalid memory access at %SSR0: 00000000.00000000 =
%SRR1:10000000.00081000
>=20
> Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03
> . . . (omitted material) . . .
> ok
> 0 >
>=20
> The only options at this point are:
>=20
> mac-boot
> shut-down
>=20
> The problem here is a different code order and a matching
> wrong start address that does not track the difference.
> (=46rom objdump.) Note: the same 0(r2) vs. -32760(r2) oddity
> exists in the start routine as well.
>=20
> Disassembly of section .text:
> 0000000000100160 <.__start-0x2030> std r2,40(r1)
> 0000000000100164 <.__start-0x202c> addis r2,r2,1
> 0000000000100168 <.__start-0x2028> addi r2,r2,-8
> 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 =
<.cpu_switch>
> 0000000000100170 <.__start-0x2020> std r2,40(r1)
> 0000000000100174 <.__start-0x201c> addis r2,r2,1
> 0000000000100178 <.__start-0x2018> addi r2,r2,-8
> 000000000010017c <.__start-0x2014> b 0000000000ade6c8 =
<.sf_buf_alloc>
> 0000000000100180 <.__start-0x2010> std r2,40(r1)
> 0000000000100184 <.__start-0x200c> addis r2,r2,1
> 0000000000100188 <.__start-0x2008> addi r2,r2,-8
> 000000000010018c <.__start-0x2004> b 0000000000a83f78 =
<.vm_fault_hold>
> 0000000000100190 <.__start-0x2000> std r2,40(r1)
> 0000000000100194 <.__start-0x1ffc> addis r2,r2,1
> 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8
> 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 =
<.fill_regs32>
> 00000000001001a0 <.__start-0x1ff0> std r2,40(r1)
> 00000000001001a4 <.__start-0x1fec> addis r2,r2,1
> 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8
> 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 =
<.casueword32>
> 00000000001001b0 <.__start-0x1fe0> std r2,40(r1)
> 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1
> 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8
> 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 =
<.kmap_free_wakeup>
> . . .
> 0000000000102190 <.__start> mfmsr r20
> 0000000000102194 <.__start+0x4> li r21,1
> 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0
> 000000000010219c <.__start+0xc> mtmsrd r20
> 00000000001021a0 <.__start+0x10> isync
> 00000000001021a4 <.__start+0x14> nop
> 00000000001021a8 <.__start+0x18> b 00000000001021b0 =
<.__start+0x20>
> 00000000001021ac <.__start+0x1c> nop
> 00000000001021b0 <.__start+0x20> nop
> 00000000001021b4 <.__start+0x24> bl 00000000001021c0 =
<.__start+0x30>
> 00000000001021b8 <.__start+0x28> .long 0x0
> 00000000001021bc <.__start+0x2c> .long 0xfc8e48
> 00000000001021c0 <.__start+0x30> mflr r2
> 00000000001021c4 <.__start+0x34> ld r1,0(r2)
> 00000000001021c8 <.__start+0x38> add r2,r1,r2
> 00000000001021cc <.__start+0x3c> ld r31,-32768(r2)
> 00000000001021d0 <.__start+0x40> subf r31,r31,r2
> 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. =
-32760 oddity!!!
> 00000000001021d8 <.__start+0x48> addi r1,r1,16288
> 00000000001021dc <.__start+0x4c> add r1,r1,r31
> 00000000001021e0 <.__start+0x50> std r3,48(r1)
> 00000000001021e4 <.__start+0x54> std r4,56(r1)
> 00000000001021e8 <.__start+0x58> std r5,64(r1)
> 00000000001021ec <.__start+0x5c> std r6,72(r1)
> 00000000001021f0 <.__start+0x60> bl 00000000001021fc =
<.__start+0x6c>
> 00000000001021f4 <.__start+0x64> .long 0x0
> 00000000001021f8 <.__start+0x68> .long 0xfd4014
> 00000000001021fc <.__start+0x6c> mflr r3
> 0000000000102200 <.__start+0x70> ld r4,0(r3)
> 0000000000102204 <.__start+0x74> add r3,r4,r3
> 0000000000102208 <.__start+0x78> mr r4,r31
> 000000000010220c <.__start+0x7c> bl 0000000000101a20 =
<begin+0x1a20>
> 0000000000102210 <.__start+0x80> ld r2,40(r1)
> 0000000000102214 <.__start+0x84> ld r3,48(r1)
> 0000000000102218 <.__start+0x88> ld r4,56(r1)
> 000000000010221c <.__start+0x8c> ld r5,64(r1)
> 0000000000102220 <.__start+0x90> ld r6,72(r1)
> 0000000000102224 <.__start+0x94> mr r4,r2
> 0000000000102228 <.__start+0x98> bl 00000000001019a0 =
<begin+0x19a0>
> 000000000010222c <.__start+0x9c> ld r2,40(r1)
> 0000000000102230 <.__start+0xa0> mr r1,r3
> 0000000000102234 <.__start+0xa4> li r3,0
> 0000000000102238 <.__start+0xa8> std r3,0(r1)
> 000000000010223c <.__start+0xac> bl 00000000005c6b28 =
<.mi_startup>
> 0000000000102240 <.__start+0xb0> nop
> 0000000000102244 <.__start+0xb4> b 0000000000102244 =
<.__start+0xb4>
>=20
>=20
> Who is most appropriate to send such information to for powerpc64?
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to =
"freebsd-toolchain-unsubscribe@freebsd.org"
_______________________________________________
freebsd-ppc@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:00:58 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A41AC6FFE1
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 03:00:58 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 ED8C31963
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:00:57 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA30vLA045139
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:00:57 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215125] clang: Turning on sanitizer options causes the test for
non-existent function mallinfo() to pass
Date: Sat, 10 Dec 2016 03:00:57 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: 11.0-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-215125-29464-cBnLqHpBYa@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215125-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215125-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 03:00:58 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215125
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o
| |rg
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:09:36 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FC75C6F683
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 03:09:36 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 6ECB47ED
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:09:36 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA39ah9042367
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:09:36 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215107] head -r309656 clang 3.9.0 for TARGET_ARCH=powerpc:
-mminimal-toc rejected (missing llvm 19098 fix?)
Date: Sat, 10 Dec 2016 03:09:36 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords: patch
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to keywords
Message-ID: <bug-215107-29464-bkbWgfRc7g@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215107-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215107-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 03:09:36 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215107
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o
| |rg
Keywords| |patch
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:23:16 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5866C6F120
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 03:23:16 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 A4499195B
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:23:16 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3NGxY069751
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:23:16 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215039] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based
buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts
and rejects .S file contents
Date: Sat, 10 Dec 2016 03:23:16 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-215039-29464-d8pDXpqBEj@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215039-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215039-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 03:23:16 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o
| |rg
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:28:33 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86FDCC6F851
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 03:28:33 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 76A1A84
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:28:33 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3SWTw014563
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:28:33 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 214973] bmake segfault on parenthesized variables.
Date: Sat, 10 Dec 2016 03:28:33 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: 11.0-STABLE
X-Bugzilla-Keywords: patch
X-Bugzilla-Severity: Affects Many People
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords assigned_to
Message-ID: <bug-214973-29464-OnhKQgD13o@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-214973-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-214973-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 03:28:33 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214973
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o
| |rg
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:29:14 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC494C6F99A
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 03:29:14 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 B963B1BE
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:29:14 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3TEaw029083
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:29:14 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 214971] clang + lld 3.9.1: Unhandled relocation 1031
Date: Sat, 10 Dec 2016 03:29:14 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Many People
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-214971-29464-y0SsKXkXrR@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-214971-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-214971-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 03:29:14 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214971
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o
| |rg
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:33:35 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FA74C6FEE8
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 03:33:35 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 F2CAFB9F
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:33:34 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3XYOT053705
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 03:33:34 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64
buildkernel stops for: rejected assembler notation in hwpmc_e500.c
Date: Sat, 10 Dec 2016 03:33:35 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords: patch
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords
Message-ID: <bug-214904-29464-5cGmCUleUV@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-214904-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-214904-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 03:33:35 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 08:50:30 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7252C6FB7F
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 08:50:30 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 96CF81DB0
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 08:50:30 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA8oUKr068770
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 08:50:30 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215193] lib/libc++: convert to a private library
Date: Sat, 10 Dec 2016 08:50:30 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords: feature
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jbeich@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform
op_sys bug_status keywords bug_severity priority component assigned_to
reporter dependson
Message-ID: <bug-215193-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 08:50:30 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215193
Bug ID: 215193
Summary: lib/libc++: convert to a private library
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: feature
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-toolchain@FreeBSD.org
Reporter: jbeich@FreeBSD.org
Depends on: 215192
libc++ version is currently tied to a specific FreeBSD release. If third-pa=
rty
software depends on bleeding edge C++ features it may fail to build. And
pulling newer version from ports is risky due to ABI mismatch. To avoid
Perl-style blunder let's promote the port version instead.
For example, FreeBSD 10.x cannot benefit from complete C++14 support.
Referenced Bugs:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215192
[Bug 215192] devel/libc++: phase out usage as part of
USES=3Dcompiler:gcc-c++11-lib
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 08:52:56 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E93BC6FD3E
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 08:52:56 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 F1EB2F5
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 08:52:55 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA8qtxS079491
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 08:52:55 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215193] libc++ and libcxxrt: convert to a private library
Date: Sat, 10 Dec 2016 08:52:56 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords: feature
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jbeich@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: short_desc
Message-ID: <bug-215193-29464-7M2akPOLTx@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215193-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215193-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 08:52:56 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215193
Jan Beich (mail not working) <jbeich@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|lib/libc++: convert to a |libc++ and libcxxrt:
|private library |convert to a private
| |library
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 09:24:27 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BB5AC7067F
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 09:24:27 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 5B5CC1026
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 09:24:27 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA9OR3O014088
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 09:24:27 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215193] libc++ and libcxxrt: convert to a private library
Date: Sat, 10 Dec 2016 09:24:27 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords: feature
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jbeich@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-215193-29464-jQzN6AegMn@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215193-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215193-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 09:24:27 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215193
--- Comment #1 from Jan Beich (mail not working) <jbeich@FreeBSD.org> ---
Another issue is on libc++-enabled systems libstdc++ from ports cannot be u=
sed.
theraven@ proposed to link libstdc++ against libcxxrt (like in gcc42 case) =
but
that often requires bleeding edge version of it. 11.0+ release model should
accelerate updates adoption but relying on libsupc++ compatibility still le=
aves
some gaps as FreeBSD tries to maintain ABI instead of leaving it to upstrea=
m.
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 11:09:12 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id E47B7C70303
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 11:09:12 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 D41B51F7C
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 11:09:12 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBAB9Ctg012179
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 11:09:12 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215193] libc++ and libcxxrt: convert to a private library
Date: Sat, 10 Dec 2016 11:09:13 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords: feature
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: theraven@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-215193-29464-UJqNcB2wEz@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215193-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215193-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 11:09:13 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215193
David Chisnall <theraven@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |theraven@FreeBSD.org
--- Comment #2 from David Chisnall <theraven@FreeBSD.org> ---
I think that a better solution to this would be more frequent upstream impo=
rts
into base (which should become a lot easier to push to users once we have
packaged base). Making libc++ a private library would mean that it would n=
ot
be possible for users to compile C++ programs without installing a port, wh=
ich
would be a major regression. If we did that, then there's little point hav=
ing
a C++ compiler in the base system at all.
Libc++ aims to be backwards binary compatible, and so there shouldn't be any
POLA violations from installing a newer one.
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-toolchain@freebsd.org Sat Dec 10 14:49:52 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id A370DC6F2EB
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Sat, 10 Dec 2016 14:49:52 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(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 923461083
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 14:49:52 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBAEnq3U013657
for <freebsd-toolchain@FreeBSD.org>; Sat, 10 Dec 2016 14:49:52 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-toolchain@FreeBSD.org
Subject: [Bug 215125] clang: Turning on sanitizer options causes the test for
non-existent function mallinfo() to pass
Date: Sat, 10 Dec 2016 14:49:52 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: 11.0-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: dim@FreeBSD.org
X-Bugzilla-Status: In Progress
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: dim@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc assigned_to bug_status
Message-ID: <bug-215125-29464-gbYWFEsWIB@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215125-29464@https.bugs.freebsd.org/bugzilla/>
References: <bug-215125-29464@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 14:49:52 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215125
Dimitry Andric <dim@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dim@FreeBSD.org
Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org
|rg |
Status|New |In Progress
--- Comment #1 from Dimitry Andric <dim@FreeBSD.org> ---
Interesting, this is because the sanitizers have several interceptors for
Linux-specific functions and variables, and these cause the link to succeed.
I will check with upstream how we can best solve this. Most likely these
interceptors should be disabled completely for FreeBSD.
--=20
You are receiving this mail because:
You are the assignee for the bug.=