From owner-freebsd-toolchain@freebsd.org Sun Jan 1 08:34:30 2017 Return-Path: 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 7E421C9ACB1 for ; Sun, 1 Jan 2017 08:34: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 62164187B for ; Sun, 1 Jan 2017 08:34: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 v018YURr066482 for ; Sun, 1 Jan 2017 08:34:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215681] head -r310854: TARGET_ARCH=powerpc buildkernel via clang 3.9.1: sys/powerpc/aim/trap_subr32.S:409:2: error: too few operands for instruction Date: Sun, 01 Jan 2017 08:34:30 +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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 08:34:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215681 --- Comment #1 from Mark Millard --- (In reply to Mark Millard from comment #0) Noting the SRC_ENV_CONF in use for the amd64 -> powerpc cross buildkernel: Script started on Sat Dec 31 00:15:10 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-bootstrap.amd64-h= ost WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/powerpc64vtsc_clang_kernel= make -j 4 buildkernel # more ~/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host=20 TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D 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 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 2 07:52:06 2017 Return-Path: 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 B2C9FC9BAC1 for ; Mon, 2 Jan 2017 07:52:06 +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 993721230 for ; Mon, 2 Jan 2017 07:52:06 +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 v027q6R4016865 for ; Mon, 2 Jan 2017 07:52:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal Date: Mon, 02 Jan 2017 07:52:06 +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: sylvain@sylvaingarrigues.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bdrewery@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 07:52:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215684 --- Comment #2 from Sylvain Garrigues --- Thank Dimitry. Do you think it is a native-xtools bug or a poudriere one? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 2 09:03:50 2017 Return-Path: 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 93D06C9B7BE for ; Mon, 2 Jan 2017 09:03: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 82EE71EC4 for ; Mon, 2 Jan 2017 09:03: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 v0293nZ7017077 for ; Mon, 2 Jan 2017 09:03:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal Date: Mon, 02 Jan 2017 09:03: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: sylvain@sylvaingarrigues.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bdrewery@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 09:03:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215684 --- Comment #3 from Sylvain Garrigues --- Also reproduced with ports-mgmt/poudriere in addition to ports-mgmt/poudrie= re=20 So as of today, it seems it is no longer possible to create an armv6 poudri= ere jail with "-x" (native-xtools)! --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 2 16:09:08 2017 Return-Path: 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 2E247C9C5F6; Mon, 2 Jan 2017 16:09:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C82B1731; Mon, 2 Jan 2017 16:09:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 3A4E310A746; Mon, 2 Jan 2017 11:09:00 -0500 (EST) From: John Baldwin To: freebsd-ppc@freebsd.org Cc: Mark Millard , FreeBSD Toolchain Subject: Re: 6.2.0 based devel/powerpc64-gcc rejects sys/powerpc/powerpc/db_trace.c for very old code Date: Mon, 02 Jan 2017 08:07:57 -0800 Message-ID: <12096354.3ltMFWEP1d@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 02 Jan 2017 11:09:00 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 16:09:08 -0000 On Tuesday, December 27, 2016 12:37:08 AM Mark Millard wrote: > I have submitted: > > Bug 215600 - devel/powerpc64-gcc based buildkernel: sys/powerpc/powerpc/db_trace.c rejected for: '__builtin_frame_address' with a nonzero argument is unsafe > > sys/powerpc/powerpc/db_trace.c -r132070 2004-Jul-12 is when this > __builtin_frame_address use was introduced: > > void > db_trace_self(void) > { > db_addr_t addr; > > addr = (db_addr_t)__builtin_frame_address(1); > db_backtrace(curthread, addr, -1); > } > > > > head was at -r310556 for this discovery but with a patch for libdwarf > in ctfconvert to enable buildkernel to get this far. I have not yet > updated to the 6.3.0 based devel/powerpc64-gcc . Try using '0' instead of '1'. You might get an extra frame in the backtrace compared to before. A simple way to test is to add 'options KDB_TRACE' and then trigger a panic (e.g. sysctl debug.kdb.panic=1) -- John Baldwin From owner-freebsd-toolchain@freebsd.org Mon Jan 2 17:40:27 2017 Return-Path: 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 1A46CC9C202 for ; Mon, 2 Jan 2017 17:40: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 094FF18E1 for ; Mon, 2 Jan 2017 17:40: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 v02HeQr9050613 for ; Mon, 2 Jan 2017 17:40:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal Date: Mon, 02 Jan 2017 17:40:26 +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: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bdrewery@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 17:40:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215684 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #4 from Dimitry Andric --- Submitted https://reviews.freebsd.org/D9026 for review. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 2 19:33:42 2017 Return-Path: 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 BEF33C9C6E7 for ; Mon, 2 Jan 2017 19:33:42 +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 A70751720 for ; Mon, 2 Jan 2017 19:33:42 +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 v02JXf9g013368 for ; Mon, 2 Jan 2017 19:33:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal Date: Mon, 02 Jan 2017 19:33:41 +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: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bdrewery@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 19:33:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215684 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Mon Jan 2 19:33:23 UTC 2017 New revision: 311131 URL: https://svnweb.freebsd.org/changeset/base/311131 Log: Make native-xtools build correctly after clang/llvm 3.9.0 import During the clang/llvm 3.9.0 import, the build structure for it was completely revamped. This broke the native-xtools target. It first attempts to build libllvmminimal, then the llvm-tblgen and clang-tblgen executables, but these fail to link because they are linked to the 'full' libllvm by default, as they normally are during the 'world' stage. To make these link against libllvmminimal instead, define TOOLS_PREFIX, similarly as during the bootstrap-tools phase. The value itself is empty, as we don't really want to use a prefix. Reviewed by: imp PR: 215684 MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D9026 Changes: head/Makefile.inc1 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 3 08:45:28 2017 Return-Path: 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 EDDB7C9CB0B for ; Tue, 3 Jan 2017 08:45:28 +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 DC9E7145A for ; Tue, 3 Jan 2017 08:45:28 +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 v038jRuq056898 for ; Tue, 3 Jan 2017 08:45:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Tue, 03 Jan 2017 08:45:27 +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: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 08:45:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 --- Comment #13 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Tue Jan 3 08:45:00 UTC 2017 New revision: 430445 URL: https://svnweb.freebsd.org/changeset/ports/430445 Log: lang/gcc: clear BROKEN from consumers as 10.1 is past EOL PR: 214863 Changes: head/math/ceres-solver/Makefile head/math/saga/Makefile head/print/lilypond-devel/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 3 08:46:20 2017 Return-Path: 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 92234C9CB4B for ; Tue, 3 Jan 2017 08:46:20 +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 80AD814D1 for ; Tue, 3 Jan 2017 08:46:20 +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 v038kKqc058018 for ; Tue, 3 Jan 2017 08:46:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Tue, 03 Jan 2017 08:46:20 +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: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 08:46:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|Open |Closed --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 3 08:56:40 2017 Return-Path: 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 9C46FC9CEAC for ; Tue, 3 Jan 2017 08:56:40 +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 8A4831D5C for ; Tue, 3 Jan 2017 08:56:40 +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 v038udTT079379 for ; Tue, 3 Jan 2017 08:56:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Tue, 03 Jan 2017 08:56:39 +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: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 08:56:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 --- Comment #14 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Tue Jan 3 08:55:57 UTC 2017 New revision: 430446 URL: https://svnweb.freebsd.org/changeset/ports/430446 Log: cad/openvsp: drop 10.1 workaround (revert r428665) per EOL PR: 214863 215307 Approved by: portmgr blanket Changes: head/cad/openvsp/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jan 4 05:08:19 2017 Return-Path: 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 E3521C9E297 for ; Wed, 4 Jan 2017 05:08:19 +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 D1EE71129 for ; Wed, 4 Jan 2017 05:08:19 +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 v0458Jfn040358 for ; Wed, 4 Jan 2017 05:08:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214855] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error Date: Wed, 04 Jan 2017 05:08:20 +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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 05:08:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214855 --- Comment #2 from Mark Millard --- I retried with -r311147 and the failure repeated. clang 3.9.1 and the like have not changed the behavior of the /usr/obj/powerpc64vtsc_clang_world/powerpc.powerpc64/usr/src/tmp/usr/bin/ld when it processes as.full . --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jan 4 09:21:33 2017 Return-Path: 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 A27A5C9B50C for ; Wed, 4 Jan 2017 09:21: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 906A41CD8 for ; Wed, 4 Jan 2017 09:21: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 v049LXnf071305 for ; Wed, 4 Jan 2017 09:21:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal Date: Wed, 04 Jan 2017 09:21:33 +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: sylvain@sylvaingarrigues.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bdrewery@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 09:21:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215684 Sylvain Garrigues changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #6 from Sylvain Garrigues --- Problem solved for me with above commit. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jan 4 22:03:11 2017 Return-Path: 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 59BFBC9F68B for ; Wed, 4 Jan 2017 22:03:11 +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 48A7F117B for ; Wed, 4 Jan 2017 22:03:11 +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 v04M3BpC085985 for ; Wed, 4 Jan 2017 22:03:11 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: Wed, 04 Jan 2017 22:03:11 +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: 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:03:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904 --- Comment #3 from Mark Millard --- Comment on attachment 177812 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D177812 patch for contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td Roman Divacky reports that this patch is incomplete, quoting: . . . the patch is not finished and I don't have the time nor the resources (I would need to implement the scheduling for that instruction) to finish it. I just did it to let you continue your exploring. . . . --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jan 4 23:13:01 2017 Return-Path: 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 41A6FC9F4B2 for ; Wed, 4 Jan 2017 23:13:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 C5562132E for ; Wed, 4 Jan 2017 23:13:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8867 invoked from network); 4 Jan 2017 22:46:18 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 Jan 2017 22:46:18 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Wed, 04 Jan 2017 17:46:29 -0500 (EST) Received: (qmail 18360 invoked from network); 4 Jan 2017 22:46:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jan 2017 22:46:29 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 35FC7EC8B12; Wed, 4 Jan 2017 14:46:17 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: I've submitted llvm bugzilla report 31538 on clang 3.9.1 not supporting the mfpmr and mtpmr instructions used in dev/hwpmc/hwpmc_e500.c Message-Id: <282B1B1D-9345-4BEA-AC30-DF7D75F8C026@dsl-only.net> Date: Wed, 4 Jan 2017 14:46:16 -0800 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 23:13:01 -0000 I have submitted to llvm (matching up with FreeBSD bugzilla 214904): Bug 31538 - FreeBSD head (12) buildkernel based on clang FreeBSD's 3.9.1 = stops for mfpmr and mtpmr instructions not being supported (used in = dev/hwpmc/hwpmc_e500.c ) This report likely should be added to the depends on list in: Bug 25780 - [META] Using Clang as the FreeBSD/ppc system compiler but I leave that to someone with official FreeBSD status to judge and answer. As for FreeBSD bugzilla 214904 I recently added a note to the patch attachment that it is an incomplete patch and the person that provided it reports not having time to do more for the mfpmr and mtpmr instructions (such as handling the instruction scheduling issues). So as stands the patch basically allows more explorations for finding other issues by allowing a normal buildkernel to complete relative to this issue. (I do not have a e500 involved in my powerpc family related testing.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jan 5 03:02:57 2017 Return-Path: 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 D81C2C9C18F for ; Thu, 5 Jan 2017 03:02:57 +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 C6A3E1692 for ; Thu, 5 Jan 2017 03:02: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 v0532vla066187 for ; Thu, 5 Jan 2017 03:02:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215681] head -r310854: TARGET_ARCH=powerpc buildkernel via clang 3.9.1: sys/powerpc/aim/trap_subr32.S:409:2: error: too few operands for instruction Date: Thu, 05 Jan 2017 03:02:58 +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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 03:02:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215681 --- Comment #2 from Mark Millard --- (In reply to Mark Millard from comment #1) [Possibly to be treated as a kernel source code issue instead of a toolchain issue! Reassign?] It turns out that only one "normal" ppc instruction had such a syntactic rejection by llvm. So this is not a general syntax mismatch for clang 3.9.1 . I'd guess that the below means that the kernel source will be updated to avoid the problem. I've no clue if FreeBSD would request llvm to allow the assembler syntax that was rejected as well. clang 3.9.1 is not allowing the optional crD to be optional in the instruction format: cmp [crD,]L,rA,rB The following: # svnlite diff /usr/src/sys/powerpc/aim/trap_subr32.S Index: /usr/src/sys/powerpc/aim/trap_subr32.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/powerpc/aim/trap_subr32.S (revision 311147) +++ /usr/src/sys/powerpc/aim/trap_subr32.S (working copy) @@ -406,7 +406,7 @@ mtctr %r1 /* load counter */ im1: lwzu %r1, 8(%r2) /* get next pte */ - cmp 0, %r1, %r3 /* see if found pte */ + cmp 0, 0, %r1, %r3 /* see if found pte */ bdnzf 2, im1 /* dec count br if cmp ne and if * count not zero */ bne instr_sec_hash /* if not found set up second hash allows buildkernel to finish if WEEROR=3D is used. (The above filled in the default value explicltly.) The other code in trap_subr32.S has a couple of cmp instructions and they have the extra "0," already: . . . dm1: lwzu %r1, 8(%r2) /* get next pte */ cmp 0, 0, %r1, %r3 /* see if found pte */ bdnzf 2, dm1 /* dec count br if cmp ne and if * count not zero */ . . . ds1: lwzu %r1, 8(%r2) /* get next pte */ cmp 0, 0, %r1, %r3 /* see if found pte */ bdnzf 2, ds1 /* dec count br if cmp ne and if * count not zero */ So it appears that having the "extra" 0, is normal for the powerpc kernel sources. Extra information: The next error that buildkernel stopped at without WERROR=3D being in use was: --- adb_mouse.o --- /usr/src/sys/dev/adb/adb_mouse.c:523:21: error: implicit conversion from 'i= nt' to 'int8_t' (aka 'signed char') changes value from 128 to -128 [-Werror,-Wconstant-conversion] sc->packet[0] =3D 1 << 7; ~ ~~^~~~ 1 error generated. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Jan 5 13:37:57 2017 Return-Path: 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 7D3CECA0FC7 for ; Thu, 5 Jan 2017 13:37:57 +0000 (UTC) (envelope-from admin@x224.save85off.com) Received: from x224.save85off.com (x224.save85off.com [43.240.238.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8031B6C for ; Thu, 5 Jan 2017 13:37:56 +0000 (UTC) (envelope-from admin@x224.save85off.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=save85off; d=x224.save85off.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=admin@x224.save85off.com; bh=TRTHfQWfzp+RhnD7K2Lye8LhDFQ=; b=HiPYLeG1MOK8jTI2IMvsfLcw7w0G12Q2wBPKkl6OUaEa6lN/cTJloYRBM1P9XW9Hw4oxJDYJGTzr AD7H1AA2B6H4qy2QFD2ow8OPDcznzYD6oySBet2Z7q2wt2iSHxFueZqMUQkCtdWaCYPY6jaLp9XZ tu7QU0eqGI0GPqaApPY= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=save85off; d=x224.save85off.com; b=P7Z+JwOp+rkDtnYlSTdbKBvZDzQZhNdvPCr17+NNBhpohEltl7QFmzN/ryLdy3+A3LaS/AH17uZM Avu91jU7DqwT36QCTu9helQu2iaCru00tp1RUl3AmsnlrEL+iTymCE6DYKCJDg/P5qYIdcTVJnpX 9rvVjuYQu2bHqtGMlYA=; From: "Michael Kors Discount" To: freebsd-toolchain@freebsd.org Date: 5 Jan 2017 21:27:57 +0800 Subject: Christmas Event Starts now! win 75$ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:37:57 -0000 From owner-freebsd-toolchain@freebsd.org Thu Jan 5 20:33:28 2017 Return-Path: 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 72F33CA1C46; Thu, 5 Jan 2017 20:33:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CE6B10BD; Thu, 5 Jan 2017 20:33:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x242.google.com with SMTP id 71so3571456ioe.0; Thu, 05 Jan 2017 12:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=P+8OKjgap3hGVltIG6TVdPs2pQDQyVA1P6ISJHTbgZw=; b=KzK/B4CZpYnolfO1fs5xS3FW3A/6hGP4v7S2Jai/v/98RvA7cz6VyAFN4xwnw+1Uth ttQKqZ5hCgI8mgp0gZNtLdg6I0T+42UQaumFvbclBbWdonI7jty5QYcaq9P+txSHIN8t 5d65sW5OUDnxPy/lnqw/aWAwOmXylRUTICai83I9zseYxyUkO2jNr1NE1HcEZzToQnjP w3lbdaITk8vbni5xj3OXHiOWZHvL49sffE+0ACxPm6fW1rXO55kdoynIW4mk9TRcYg8v fd/PwH5ee6xN+jzPBvT7xMqUqqa4Dj7r98R2XlChcZtWHK+y96ZxbQUP6jdXydrmfi4P 90CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=P+8OKjgap3hGVltIG6TVdPs2pQDQyVA1P6ISJHTbgZw=; b=U0JaRiA/RvYvvAZucFYpP4kIv0MEsOloxqb5NXrm6B3PkukvZdTlbnQa4JkY0/Pzv2 x/epX44r+00MTr25SW9hgkRrAj1P1noD10/r/qwTdE/rZY/SJVfxk1iTNoe3FmDdQfWz jSSDlbO8DUv3YgdAMgeF2sG0sGhlyabUwmdjwGGCPCw3LpWTKtpH7HTMsQTHPzNDggkx uCZY4QfiB1kwGz9cbGBxj2enlan02Q5KszYFN7nq+4/CQujReqypKM6oTa9QbPywahnx CB3miL6aUvBwpXd9JtI+LysDVuxPNrXFucKecq872v0KGDDtoEBvbjscXAzXlh+LM1id 7Kxg== X-Gm-Message-State: AIkVDXIVvf0nbSVm0X20yYi67GwiVEk2+vI3KeSzNzki87+FGBi9KJOsB4tXCBh7RRM9YdghqHyBGGy4bLv+DA== X-Received: by 10.107.162.204 with SMTP id l195mr55386781ioe.169.1483648407472; Thu, 05 Jan 2017 12:33:27 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.175.133 with HTTP; Thu, 5 Jan 2017 12:33:06 -0800 (PST) In-Reply-To: <282B1B1D-9345-4BEA-AC30-DF7D75F8C026@dsl-only.net> References: <282B1B1D-9345-4BEA-AC30-DF7D75F8C026@dsl-only.net> From: Ed Maste Date: Thu, 5 Jan 2017 15:33:06 -0500 X-Google-Sender-Auth: zAZxNXNs5_SvdYpUeWxdwPnvXUo Message-ID: Subject: Re: I've submitted llvm bugzilla report 31538 on clang 3.9.1 not supporting the mfpmr and mtpmr instructions used in dev/hwpmc/hwpmc_e500.c To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 20:33:28 -0000 On 4 January 2017 at 17:46, Mark Millard wrote: > I have submitted to llvm (matching up with FreeBSD bugzilla 214904): > > Bug 31538 - FreeBSD head (12) buildkernel based on clang FreeBSD's 3.9.1 stops for mfpmr and mtpmr instructions not being supported (used in dev/hwpmc/hwpmc_e500.c ) Thank you. > This report likely should be added to the depends on list in: > > Bug 25780 - [META] Using Clang as the FreeBSD/ppc system compiler Agreed, I've added it there. Please feel free to add other issues you find as blocking 25780; my intent is to have it track all of the outstanding issues preventing a Clang-based "make buildworld buildkernel" from succeeding on any ppc / ppc64. From owner-freebsd-toolchain@freebsd.org Thu Jan 5 22:23:02 2017 Return-Path: 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 6EA2ACA10CD for ; Thu, 5 Jan 2017 22:23:02 +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 20E251F2D for ; Thu, 5 Jan 2017 22:23:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2834 invoked from network); 5 Jan 2017 22:16:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 5 Jan 2017 22:16:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 05 Jan 2017 17:16:32 -0500 (EST) Received: (qmail 15834 invoked from network); 5 Jan 2017 22:16:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jan 2017 22:16:32 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 20F18EC900C; Thu, 5 Jan 2017 14:16:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: I've submitted llvm bugzilla report 31538 on clang 3.9.1 not supporting the mfpmr and mtpmr instructions used in dev/hwpmc/hwpmc_e500.c From: Mark Millard In-Reply-To: Date: Thu, 5 Jan 2017 14:16:19 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <282B1B1D-9345-4BEA-AC30-DF7D75F8C026@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:23:02 -0000 On 2017-Jan-5, at 12:33 PM, Ed Maste wrote: > On 4 January 2017 at 17:46, Mark Millard = wrote: >> I have submitted to llvm (matching up with FreeBSD bugzilla 214904): >>=20 >> Bug 31538 - FreeBSD head (12) buildkernel based on clang FreeBSD's = 3.9.1 stops for mfpmr and mtpmr instructions not being supported (used = in dev/hwpmc/hwpmc_e500.c ) >=20 > Thank you. >=20 >> This report likely should be added to the depends on list in: >>=20 >> Bug 25780 - [META] Using Clang as the FreeBSD/ppc system compiler >=20 > Agreed, I've added it there. Please feel free to add other issues you > find as blocking 25780; my intent is to have it track all of the > outstanding issues preventing a Clang-based "make buildworld > buildkernel" from succeeding on any ppc / ppc64. Thanks and okay. I'll take "succeeding" to include being operational, not just having the builds complete. For example: builds complete but C++ exception handling is completely broken in operation. Even trivial examples fail if they throw an exception. I take devel/kyua being able to be used as going along with buildworld and buildkernel --and that requires C++ exception handling being in working order. (Sound appropriate to include devel/kyua as part of the criteria so that the test environment works?) My bias is to not list things in 25780 that have trivial source code changes for FreeBSD that avoid the issue. And example is the matching-pair: llvm bugzilla 31541 / FreeBSD bugzilla 21568 In this context explicitly supplying one supposedly optional assembler instruction operand in one place in one .S sidesteps the clang's mishandling of the optional status. With WERROR=3D buildkernel was able to "complete" when I made that change in my environment. [In fact the other examples of the instruction in question in that .S file have the optional operand explicitly listed.] ["Complete": because, for example, I've a workaround for the hwpmc_e500.c rejection in place already in order to explore looking for the "next problem". Thus the starting point is not pure head or pure stable/11 in various of my reports.] There are issues not tied to llvm, such as needing to use older versions of devel/binutils and devel/powerpc64-binutils . The slave-port relationship means that to have devel/powerpc64-binutils be older requires devel/binutils to also be older. In my context this is an unfortunate tie for my cross build context but I'm sticking to the Makefiles from svn for such. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Jan 6 05:39:40 2017 Return-Path: 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 594F2CA1544 for ; Fri, 6 Jan 2017 05:39:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 171A518B5 for ; Fri, 6 Jan 2017 05:39:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28220 invoked from network); 6 Jan 2017 05:39:33 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Jan 2017 05:39:33 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 06 Jan 2017 00:39:33 -0500 (EST) Received: (qmail 29060 invoked from network); 6 Jan 2017 05:39:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jan 2017 05:39:32 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 2ABB8EC7F2C; Thu, 5 Jan 2017 21:39:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: <20161212210922.GA27403@vlakno.cz> Date: Thu, 5 Jan 2017 21:39:31 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> References: <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> To: Roman Divacky , Justin Hibbits , Nathan Whitehorn X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 05:39:40 -0000 [Summary: I tracked the boot code problem back to clang 3.9.x using = R_PPC64_ADDR16_DS with .toc in locore.o (that does not work) but xtoolchain using = R_PPC64_TOC16_DS with .toc in locore.o (that does work).] On 2016-Dec-12, at 1:09 PM, Roman Divacky wrote: > Ping.... Can you take a look Nathan? >=20 > Thanks! Roman >=20 > On Thu, Dec 08, 2016 at 11:14:52PM +0100, Roman Divacky wrote: >> I believe the code comes from sys/powerpc/aim/locore64.S and if you = compare >> the different values from the disssembly with the .S code you can see >> it's __tocbase and TOC_REF(). >>=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 >>=20 >> 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 = 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 = >>> 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 = >>> 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 Note: I discovered with file that the bootstrap binutils and devel/binutils (and devel/powerpc64-binutils) produce differing types of files: bootstrap binutils: sys/GENERIC64vtsc-NODBG/kernel: ELF 64-bit MSB = shared object (only tried with clang) devel/*binutils: sys/GENERIC64vtsc-NODBG/kernel: ELF 64-bit MSB = executable (both clang and xtoolchain tried) It is the devel/*binutils used with xtoolchain that produces what boots. For the devel/*binutils (with clang vs. xtoolchain) . . . Using objdump on locore.o I see variations based on clang vs. = xtoolchain, including the below relative to .toc handling: (- -> clang , + -> xtoolchain) RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 . . . -0000000000000046 R_PPC64_ADDR16_DS .toc +0000000000000046 R_PPC64_TOC16_DS .toc . . . -0000000000000182 R_PPC64_ADDR16_DS .toc +0000000000000182 R_PPC64_TOC16_DS .toc . . . -0000000000000916 R_PPC64_ADDR16_DS .toc . . . +0000000000000916 R_PPC64_TOC16_DS .toc . . . In the boot code (/boot/kernel/kernel) these match up with. . . Disassembly of section .text: 0000000000100160 <.__start> mfmsr r20 # clang vs. Disassembly of section .text: 0000000000100120 <.__start> mfmsr r20 # xtoolchain . . . 00000000001001a4 <.__start+0x44> ld r1,0(r2) # 100160+46 = clang vs. 0000000000100164 <.__start+0x44> ld r1,-32760(r2) # 100120+46 = xtoolchain . . . 00000000001002e0 ld r1,0(r2) # 100160+182 = clang vs. 00000000001002a0 ld r1,-32760(r2) # 100120+182 = xtoolchain . . . 0000000000100a74 ld r1,0(r1) # 100160+916 = clang vs. 0000000000100a34 ld r1,-32760(r1) # 100120+916 = xtoolchain =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Jan 6 09:10:53 2017 Return-Path: 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 B59A6B88DF7 for ; Fri, 6 Jan 2017 09:10:53 +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 659941066 for ; Fri, 6 Jan 2017 09:10:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7801 invoked from network); 6 Jan 2017 09:04:33 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Jan 2017 09:04:33 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 06 Jan 2017 04:04:26 -0500 (EST) Received: (qmail 18080 invoked from network); 6 Jan 2017 09:04:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jan 2017 09:04:26 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id E653AEC913D; Fri, 6 Jan 2017 01:04:10 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Bug 215821 for TARGET_ARCH=powerpc64: bootstrapped ld produces a "shared object" when given a -pie option; junk kernel produced crashes Message-Id: <496BD75E-3D29-4717-BDE8-9AAFCA27FD0C@dsl-only.net> Date: Fri, 6 Jan 2017 01:04:10 -0800 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 09:10:53 -0000 I have submitted a FreeBSD bugzilla entry: Bug 215821 - head -r311147's bootstrapped ld for TARGET_ARCH=3Dpowerpc64 = produces kernel.full as a "shared object" for -pie instead of as a = "executable": booting the produced kernel crashes In essence what the .meta file for kernel.full shows as: CMD @ld -Bdynamic -T /usr/src/sys/conf/ldscript.powerpc64 -pie = --no-warn-mismatch --warn-common --export-dynamic --dynamic-linker = /red/herring -o kernel.full -X locore.o . . . (note the -pie) ends up producing: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 = (FreeBSD), dynamically linked, interpreter /red/herring, not stripped instead of what it should have produced: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 = (FreeBSD), dynamically linked, interpreter /red/herring, not stripped The differences in content leads to the powerpc64 crashing at the start = of the produced kernel. This means needing to use devel/binutils and/or devel/powerpc64-binutils = instead (at least for ld). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Jan 6 09:20:40 2017 Return-Path: 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 D4A1FCA01E9 for ; Fri, 6 Jan 2017 09:20:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 8A560147C for ; Fri, 6 Jan 2017 09:20:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15528 invoked from network); 6 Jan 2017 09:20:39 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Jan 2017 09:20:39 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 06 Jan 2017 04:20:53 -0500 (EST) Received: (qmail 17832 invoked from network); 6 Jan 2017 09:20:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jan 2017 09:20:53 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 24B99EC913D; Fri, 6 Jan 2017 01:20:38 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Bug 215819: clang 3.9.1 for TARGET_ARCH=powerpc64 generated R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc; 0(register) addressing results and crashes the kernel Message-Id: Date: Fri, 6 Jan 2017 01:20:37 -0800 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 09:20:40 -0000 [As stands I've no clue if this is unique to FreeBSD's clang somehow vs. if it is a general llvm powerpc64 problem. This may need a llvm submittal as well.] I have submitted FreeBSD bugzilla entry: Bug 215819 - head r311147's clang 3.9.1 for powerpc64: locore.o = generation messed up: generates R_PPC64_ADDR16_DS instead of = R_PPC64_TOC16_DS with .toc=20 Using objdump on locore.o I see variations based on clang vs. = xtoolchain, including the below relative to .toc handling: (- -> clang , + -> xtoolchain) RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 . . . -0000000000000046 R_PPC64_ADDR16_DS .toc +0000000000000046 R_PPC64_TOC16_DS .toc . . . -0000000000000182 R_PPC64_ADDR16_DS .toc +0000000000000182 R_PPC64_TOC16_DS .toc . . . -0000000000000916 R_PPC64_ADDR16_DS .toc . . . +0000000000000916 R_PPC64_TOC16_DS .toc . . . (The above is based on objdump output differences.) In the boot code (/boot/kernel/kernel) these match up with. . . . . . <.__start+0x44> ld r1,0(r2) # 100160+46 clang vs. <.__start+0x44> ld r1,-32760(r2) # 100120+46 xtoolchain . . . ld r1,0(r2) # 100160+182 clang vs. ld r1,-32760(r2) # 100120+182 xtoolchain . . . ld r1,0(r1) # 100160+916 clang vs. ld r1,-32760(r1) # 100120+916 xtoolchain (Based on more objdump output comparisons.) clang's code does not boot; xtoolchain's code does. In both cases devel/powerpc64-binutils was used instead of bootstrapped binutils to produce the kernel.full file and the like (because of the bootstrapped ld having its own problems). But if locore.o should have used R_PPC64_TOC16_DS for clang 3.9.1 then that is an earlier problem. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Jan 6 15:19:36 2017 Return-Path: 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 A1FA0CA2AC9; Fri, 6 Jan 2017 15:19:36 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C8E61E52; Fri, 6 Jan 2017 15:19:36 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-qk0-x22f.google.com with SMTP id a20so78124695qkc.1; Fri, 06 Jan 2017 07:19:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=q8qBlplW4hmqZa3X+sg1XfesZaBU5y2khuCRd6UixIc=; b=uoy+t5/2rPIQ4GDlfEtPIqonwR7GRiIjd5K7FIycUe9YB8MOudA2Gu68jTmtc3/whv OnNQ0un6m79z+1EmnMpJP2NEjEINYlaUNGJA0kF+AGBgdcbonaLgG0osqMg3o4Krhobx Nmxns2eR8YmWSX+tXNzJS2ocZko823pjOoEscYJkFPk8AjCEBoNjfiUiEt2reYIAljEX JnN2O27O0PUM07OwJ+g7vqGLufmmItvnaoRstgWDzGhHYoXcRtIkqdu7gWENxrZ2GL9I lEzSYjA5K4Pr9rz6KwXM3x3aF8fuXSFyV6lBRLCCFDWnPmjh2vrLSyE4mAJ9SBnmWqNq 2szg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=q8qBlplW4hmqZa3X+sg1XfesZaBU5y2khuCRd6UixIc=; b=sdptiSN6csDnFRSbsE9FR/v+QuSC9Z6A2g9uD6PWzE8vq3bqEq08c03fjFJT9Ch3rm k7fhNjDLbYR83nVB8YOfua7zG3MjrD4HHoQdkxQ9VQmE1MwBpUHF0ZAYmtgJ3MW+X3nH XlpWjZHKNND01cUeh7gKjifY0HpRbtp8JqPekoVoOIPcxI694u+2gNNTzT87FvDk7LRc B5T8BT5PzuqGYoMl0inSYxJEOA3ihFdYvCslZyXv7UDbGsi1rrwasFobC4FXD+QzWq9j YZeOxhIR7aiARIYdZsL4lpiGqsCz8aM0PWdy1mVDPeu/wUsEGCzN+x6p2M3HVVRtH1Af HJqw== X-Gm-Message-State: AIkVDXKTItgJQn6U+Yuu4vswh+CkVFKiahMHAfGo3P0XtGrpP+Z0hQPjl4Do9IwH2xaQYCKhDfGCkioJ4iDDJg== X-Received: by 10.55.160.65 with SMTP id j62mr69859999qke.239.1483715975491; Fri, 06 Jan 2017 07:19:35 -0800 (PST) MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.12.157.66 with HTTP; Fri, 6 Jan 2017 07:19:34 -0800 (PST) In-Reply-To: <496BD75E-3D29-4717-BDE8-9AAFCA27FD0C@dsl-only.net> References: <496BD75E-3D29-4717-BDE8-9AAFCA27FD0C@dsl-only.net> From: Justin Hibbits Date: Fri, 6 Jan 2017 09:19:34 -0600 X-Google-Sender-Auth: 4KPABkv6UPVLMELJgsCwt153grg Message-ID: Subject: Re: Bug 215821 for TARGET_ARCH=powerpc64: bootstrapped ld produces a "shared object" when given a -pie option; junk kernel produced crashes To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 15:19:36 -0000 On Fri, Jan 6, 2017 at 3:04 AM, Mark Millard wrote: > I have submitted a FreeBSD bugzilla entry: > > Bug 215821 - head -r311147's bootstrapped ld for TARGET_ARCH=powerpc64 produces kernel.full as a "shared object" for -pie instead of as a "executable": booting the produced kernel crashes > > In essence what the .meta file for kernel.full shows as: > > CMD @ld -Bdynamic -T /usr/src/sys/conf/ldscript.powerpc64 -pie --no-warn-mismatch --warn-common --export-dynamic --dynamic-linker /red/herring -o kernel.full -X locore.o . . . > > (note the -pie) ends up producing: > > ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, interpreter /red/herring, not stripped > > instead of what it should have produced: > > ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, interpreter /red/herring, not stripped > > The differences in content leads to the powerpc64 crashing at the start of the produced kernel. > > This means needing to use devel/binutils and/or devel/powerpc64-binutils instead (at least for ld). > > === > Mark Millard > markmi at dsl-only.net Hi Mark, Nathan made a change 2 years ago to build the kernel as a shared object, so that it can be relocatable. Looking at my kernel.full (base gcc build): world/zhabar/home/chmeee/freebsd/pristine/sys/ZHABAR/kernel.full: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, interpreter /red/herring, not stripped - Justin From owner-freebsd-toolchain@freebsd.org Fri Jan 6 18:32:42 2017 Return-Path: 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 64E2BCA28F7 for ; Fri, 6 Jan 2017 18:32:42 +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 261291F74 for ; Fri, 6 Jan 2017 18:32:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16820 invoked from network); 6 Jan 2017 18:32:40 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Jan 2017 18:32:40 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 06 Jan 2017 13:32:51 -0500 (EST) Received: (qmail 22898 invoked from network); 6 Jan 2017 18:32:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jan 2017 18:32:51 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 3251DEC91F6; Fri, 6 Jan 2017 10:32:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Bug 215821 for TARGET_ARCH=powerpc64: bootstrapped ld produces a "shared object" when given a -pie option; junk kernel produced crashes From: Mark Millard In-Reply-To: Date: Fri, 6 Jan 2017 10:32:38 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <41E7622E-6F9E-4495-B2FD-A3F3EAC1832D@dsl-only.net> References: <496BD75E-3D29-4717-BDE8-9AAFCA27FD0C@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:32:42 -0000 On 2017-Jan-6, at 7:19 AM, Justin Hibbits = wrote: > On Fri, Jan 6, 2017 at 3:04 AM, Mark Millard = wrote: >> I have submitted a FreeBSD bugzilla entry: >>=20 >> Bug 215821 - head -r311147's bootstrapped ld for = TARGET_ARCH=3Dpowerpc64 produces kernel.full as a "shared object" for = -pie instead of as a "executable": booting the produced kernel crashes >>=20 >> In essence what the .meta file for kernel.full shows as: >>=20 >> CMD @ld -Bdynamic -T /usr/src/sys/conf/ldscript.powerpc64 -pie = --no-warn-mismatch --warn-common --export-dynamic --dynamic-linker = /red/herring -o kernel.full -X locore.o . . . >>=20 >> (note the -pie) ends up producing: >>=20 >> ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 = (FreeBSD), dynamically linked, interpreter /red/herring, not stripped >>=20 >> instead of what it should have produced: >>=20 >> ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 = (FreeBSD), dynamically linked, interpreter /red/herring, not stripped >>=20 >> The differences in content leads to the powerpc64 crashing at the = start of the produced kernel. >>=20 >> This means needing to use devel/binutils and/or = devel/powerpc64-binutils instead (at least for ld). >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > Hi Mark, >=20 > Nathan made a change 2 years ago to build the kernel as a shared > object, so that it can be relocatable. Looking at my kernel.full > (base gcc build): >=20 > world/zhabar/home/chmeee/freebsd/pristine/sys/ZHABAR/kernel.full: ELF > 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 > (FreeBSD), dynamically linked, interpreter /red/herring, not stripped >=20 > - Justin A "position independent executable" and a "shared object" are both relocatable: both are dynamically linked. (The below mentions some differences that show up.) It looks like Nathan may have tried to handle what the system ld did with -pie as well as what devel/*binutils does. (More below.) Nathon wrote in = https://lists.freebsd.org/pipermail/freebsd-ppc/2015-January/007375.html that: > This is the first architecture to have a PIE kernel, however, so I'd=20= > like some feedback on the approach. The major immediate difficulty is=20= > that PIE kernels are ET_DYN ELF executables. He said "executable", not "shared object" but also said "ET_DYN". I'll note that the flags from the different versions of ld (system binutils vs. devel/*binutils) ends up with different flags (system first, then devel/*binutils) for -pie being specified: architecture: powerpc:common64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x00000000010cf848 The above sort of case also has .branch_lt sections involved. (gcc 4.2.1 and clang, I've not tried xtoolchain mixed with the bootstrapped ld.) architecture: powerpc:common64, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x000000000108b6c8 The above sort of case does not have .branch_lt sections involved. (clang and xtoolchain, I've not tried gcc 4.2.1 with devel/*binutils based ld.) [They are not the same builds so the address difference is expected. And the start addresses do not match the "<.__start> mfmsr r20" in either case and is not where the kernel code execution starts on the PowerMac G5's.] It appears to me that the system ld and the devel/*binutils ld do not agree for what -pie generates. I would guess that -pie should involve the EXEC_P flag and so be a executable according to the flags and that an executable would not have .branch_lt . In other words: devel/*binutils is correct in that much by my guess. Another wording of that would be: for the system ld "-pie" is "in name only" or has a "special FreeBSD definition" from what I can tell. Another difference is that the EXEC_P examples from devel/*binutils later list: private flags =3D 0x1: [abiv1] at the end of the Dynamic Section but the HAS_SYMS examples do not list such an indication of the abi. But that note from Nathan also had: load_elf.c with: +#if defined(__powerpc__) && __ELF_WORD_SIZE =3D=3D 64 + } else if (ehdr->e_type =3D=3D ET_EXEC || + (ehdr->e_type =3D=3D ET_DYN && ehdr->e_entry !=3D 0)) { +#else } else if (ehdr->e_type =3D=3D ET_EXEC) { +#endif Makefile.powerpc with: +.if ${MACHINE_ARCH} =3D=3D "powerpc64" +CFLAGS+=3D -fPIC +LDFLAGS+=3D -pie +.endif kmod.mk with: +# Don't add a fake entry point to modules +_LDFLAGS+=3D -e 0 [The .meta files show the -pie option that specifies position independent executable. That includes when I use gcc 4.2.1 in the modern context.] load_elf.c suggests trying to handle what the bootstrap ld does with -pie . When I try a bootstrapped gcc 4.2.1 based buildkernel I get a kernel file with: . . . Disassembly of section .text: 0000000000100160 <.__start-0x2350> std r2,40(r1) 0000000000100164 <.__start-0x234c> addis r2,r2,1 0000000000100168 <.__start-0x2348> addi r2,r2,-520 000000000010016c <.__start-0x2344> b 0000000000368d38 = <.pci_find_dbsf> 0000000000100170 <.__start-0x2340> std r2,40(r1) . . . 00000000001024b0 <.__start> mfmsr r20 00000000001024b4 <.__start+0x4> li r21,1 00000000001024b8 <.__start+0x8> rldimi r20,r21,63,0 00000000001024bc <.__start+0xc> mtmsrd r20 00000000001024c0 <.__start+0x10> isync Note the "40(r1)" use of an uninitialized r1 if the code starts at 0000000000100160 and the branch to .pci_find_dbsf as well. With this code the execution needs to not start at 0000000000100160 . [Justin: What does your example look like for such?] Later I'll try installing and booting this gcc4.2.1 based kernel but so far it looks like other non-gcc 4.2.1 based ones that used the bootstrapped ld and that actually start at what would be 0000000000100160 in the above example above and quickly fails on the PowerMac G5 so-called "Quad Core" that I currently have access to. If it boots I'll see if I can track down another difference in how things start for kernel execution. But clang mishandles what should be R_PPC64_TOC16_DS with .toc and so the boot \ fails for lack of correct offsets in addressing, such has 0(r2) instead of something like -32760(r2). This alone blocks getting very far for booting based on clang: Both variants of ld get boot failure for clang as stands, just with some different details in how/when/where it fails. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Jan 6 22:09:47 2017 Return-Path: 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 571B6CA2078 for ; Fri, 6 Jan 2017 22:09: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 462321144 for ; Fri, 6 Jan 2017 22:09: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 v06M9kZR067845 for ; Fri, 6 Jan 2017 22:09:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215684] ports-mgmt/poudriere-devel: fails to build native-xtools because of libllvmminimal Date: Fri, 06 Jan 2017 22:09:46 +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: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bdrewery@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:09:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215684 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Fri Jan 6 22:09:00 UTC 2017 New revision: 311558 URL: https://svnweb.freebsd.org/changeset/base/311558 Log: MFC r311131: Make native-xtools build correctly after clang/llvm 3.9.0 import During the clang/llvm 3.9.0 import, the build structure for it was completely revamped. This broke the native-xtools target. It first attempts to build libllvmminimal, then the llvm-tblgen and clang-tblgen executables, but these fail to link because they are linked to the 'full' libllvm by default, as they normally are during the 'world' stage. To make these link against libllvmminimal instead, define TOOLS_PREFIX, similarly as during the bootstrap-tools phase. The value itself is empty, as we don't really want to use a prefix. Reviewed by: imp PR: 215684 Differential Revision: https://reviews.freebsd.org/D9026 Changes: _U stable/11/ stable/11/Makefile.inc1 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 6 22:35:30 2017 Return-Path: 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 553FBCA2769 for ; Fri, 6 Jan 2017 22:35: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 43AF2111D for ; Fri, 6 Jan 2017 22:35: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 v06MZU7Q031933 for ; Fri, 6 Jan 2017 22:35:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215821] head -r311147's bootstrapped ld for TARGET_ARCH=powerpc64 produces kernel.full as a "shared object" for -pie instead of as a "executable": booting the produced kernel crashes Date: Fri, 06 Jan 2017 22:35:30 +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: cc assigned_to Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:35:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215821 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org 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 Fri Jan 6 22:38:28 2017 Return-Path: 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 48302CA2846 for ; Fri, 6 Jan 2017 22:38:28 +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 36F901483 for ; Fri, 6 Jan 2017 22:38:28 +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 v06McSCn035503 for ; Fri, 6 Jan 2017 22:38:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc Date: Fri, 06 Jan 2017 22:38:28 +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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:38:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215819 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --- Comment #1 from Mark Linimon --- Reassign. It doesn't look to me like r311147 has anything to do with clang, though? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 6 22:39:54 2017 Return-Path: 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 62874CA29C2 for ; Fri, 6 Jan 2017 22:39:54 +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 51FFF1688 for ; Fri, 6 Jan 2017 22:39:54 +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 v06Mdrje037246 for ; Fri, 6 Jan 2017 22:39:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215798] clang: please Include thread sanitizer (and all other available sanitizers) Date: Fri, 06 Jan 2017 22:39:54 +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: 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 short_desc Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:39:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215798 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg Summary|clang: Include thread |clang: please Include |sanitizer (and all other |thread sanitizer (and all |available sanitizers) |other available sanitizers) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 6 22:43:37 2017 Return-Path: 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 C107FCA2FC8 for ; Fri, 6 Jan 2017 22:43:37 +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 A2A671E2B for ; Fri, 6 Jan 2017 22:43:37 +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 v06MhbKe049391 for ; Fri, 6 Jan 2017 22:43:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215821] head -r311147's bootstrapped ld for TARGET_ARCH=powerpc64 produces kernel.full as a "shared object" for -pie instead of as a "executable": booting the produced kernel crashes Date: Fri, 06 Jan 2017 22:43:37 +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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:43:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215821 --- Comment #1 from Mark Millard --- (In reply to Mark Millard from comment #0) Note: It looks like FreeBSD's ld interpretation of -pie is odd but long standing and FreeBSD may be designed to handle the oddity. Some supporting notes from a list reply follow. . . Nathon wrote in https://lists.freebsd.org/pipermail/freebsd-ppc/2015-January/007375.html that: This is the first architecture to have a PIE kernel, however, so I'd=20 like some feedback on the approach. The major immediate difficulty is=20 that PIE kernels are ET_DYN ELF executables. He said "executable", not "shared object" but also said "ET_DYN". I'll note that the flags from the different versions of ld (system binutils vs. devel/*binutils) ends up with different flags (system first, then devel/*binutils) for -pie being specified: architecture: powerpc:common64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x00000000010cf848 The above sort of case also has .branch_lt sections involved. (gcc 4.2.1 and clang, I've not tried xtoolchain mixed with the bootstrapped ld.) architecture: powerpc:common64, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x000000000108b6c8 The above sort of case does not have .branch_lt sections involved. (clang and xtoolchain, I've not tried gcc 4.2.1 with devel/*binutils based ld.) [They are not the same builds so the address difference is expected. And the start addresses do not match the "<.__start> mfmsr r20" in either case and is not where the kernel code execution starts on the PowerMac G5's.] It appears to me that the system ld and the devel/*binutils ld do not agree for what -pie generates. I would guess that -pie should involve the EXEC_P flag and so be a executable according to the flags and that an executable would not have .branch_lt . In other words: devel/*binutils is correct in that much by my guess. Another wording of that would be: for the system ld "-pie" is "in name only" or has a "special FreeBSD definition" from what I can tell. Another difference is that the EXEC_P examples from devel/*binutils later list: private flags =3D 0x1: [abiv1] at the end of the Dynamic Section but the HAS_SYMS examples do not list such an indication of the abi. But that note from Nathan also had: load_elf.c with: +#if defined(__powerpc__) && __ELF_WORD_SIZE =3D=3D 64 + } else if (ehdr->e_type =3D=3D ET_EXEC || + (ehdr->e_type =3D=3D ET_DYN && ehdr->e_entry !=3D 0)) { +#else } else if (ehdr->e_type =3D=3D ET_EXEC) { +#endif Makefile.powerpc with: +.if ${MACHINE_ARCH} =3D=3D "powerpc64" +CFLAGS+=3D -fPIC +LDFLAGS+=3D -pie +.endif kmod.mk with: +# Don't add a fake entry point to modules +_LDFLAGS+=3D -e 0 [The .meta files show the -pie option that specifies position independent executable. That includes when I use gcc 4.2.1 in the modern context.] load_elf.c suggests trying to handle what the bootstrap ld does with -pie . When I try a bootstrapped gcc 4.2.1 based buildkernel I get a kernel file with: . . . Disassembly of section .text: 0000000000100160 <.__start-0x2350> std r2,40(r1) 0000000000100164 <.__start-0x234c> addis r2,r2,1 0000000000100168 <.__start-0x2348> addi r2,r2,-520 000000000010016c <.__start-0x2344> b 0000000000368d38 <.pci_find_dbsf> 0000000000100170 <.__start-0x2340> std r2,40(r1) . . . 00000000001024b0 <.__start> mfmsr r20 00000000001024b4 <.__start+0x4> li r21,1 00000000001024b8 <.__start+0x8> rldimi r20,r21,63,0 00000000001024bc <.__start+0xc> mtmsrd r20 00000000001024c0 <.__start+0x10> isync Note the "40(r1)" use of an uninitialized r1 if the code starts at 0000000000100160 and the branch to .pci_find_dbsf as well. With this code the execution needs to not start at 0000000000100160 . [Justin: What does your example look like for such?] Later I'll try installing and booting this gcc4.2.1 based kernel but so far it looks like other non-gcc 4.2.1 based ones that used the bootstrapped ld and that actually start at what would be 0000000000100160 in the above example above and quickly fails on the PowerMac G5 so-called "Quad Core" that I currently have access to. If it boots I'll see if I can track down another difference in how things start for kernel execution. But clang mishandles what should be R_PPC64_TOC16_DS with .toc and so the boot \ fails for lack of correct offsets in addressing, such has 0(r2) instead of something like -32760(r2). This alone blocks getting very far for booting based on clang: Both variants of ld get boot failure for clang as stands, just with some different details in how/when/where it fails. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 6 22:49:26 2017 Return-Path: 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 AB764CA22EE for ; Fri, 6 Jan 2017 22:49:26 +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 9ADF511E7 for ; Fri, 6 Jan 2017 22:49:26 +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 v06MnQVs056381 for ; Fri, 6 Jan 2017 22:49:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215798] clang: please Include thread sanitizer (and all other available sanitizers) Date: Fri, 06 Jan 2017 22:49:26 +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: 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:49:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215798 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org --- Comment #1 from Dimitry Andric --- The problem is that the thread sanitizer currently does not work on FreeBSD. This has to do with the way thread sanitizer attempts to initialize very ea= rly during program startup, and it conflicts with jemalloc's early initializati= on.=20 This leads to an endless recursion, and a stack overflow. For thread sanitizer to work properly, it looks like we will need some sort= of hook in libc, which can be used to initialize thread sanitizer before jemal= loc is initialized. I have limited time, so I have not yet worked on this.=20 Patches are welcome. :-) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 6 22:49:33 2017 Return-Path: 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 854EBCA2305 for ; Fri, 6 Jan 2017 22:49: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 7450B1210 for ; Fri, 6 Jan 2017 22:49: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 v06MnXE0056516 for ; Fri, 6 Jan 2017 22:49:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc Date: Fri, 06 Jan 2017 22:49: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: 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:49:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215819 --- Comment #2 from Mark Millard --- (In reply to Mark Linimon from comment #1) -r311147 is just the version I tested. It does not show how long the problem has existed. Usually folks want to know if the current (or a recent) build still has a problem before going further. Plus it is more time and effort to back trace to the first example. In this case it is likely clang 3.9.0 and 3.9.1's whole powerpc64 history in FreeBSD: effectively I've just learned more about "already known to be broken" details and reported them. There was prior list activity about the bad register offsets such as 0(r2) but without the R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS information. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 6 23:57:45 2017 Return-Path: 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 262BDCA3604 for ; Fri, 6 Jan 2017 23:57: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 14BC51A6A for ; Fri, 6 Jan 2017 23:57: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 v06Nvih5013167 for ; Fri, 6 Jan 2017 23:57:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215681] head -r310854: TARGET_ARCH=powerpc buildkernel via clang 3.9.1: sys/powerpc/aim/trap_subr32.S:409:2: error: too few operands for instruction Date: Fri, 06 Jan 2017 23:57:45 +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-ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords assigned_to Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 23:57:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215681 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Assignee|freebsd-toolchain@FreeBSD.o |freebsd-ppc@FreeBSD.org |rg | --- Comment #3 from Mark Linimon --- Apparently only one instruction is rejected by clang. Submitter has includ= ed a patch to the kernel source file /usr/src/sys/powerpc/aim/trap_subr32.S to f= ix this. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Jan 7 09:02:46 2017 Return-Path: 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 72C6ECA3CC9; Sat, 7 Jan 2017 09:02:46 +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 1E3981201; Sat, 7 Jan 2017 09:02:45 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id CBC2112CB9F; Sat, 7 Jan 2017 09:51:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1483779087; bh=gc/gHldNLLJUX+cN5BPyoNI1y9MV4YjabpT/iaTWotk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=QEKB+agvrMa5BLMfqzhWFFGqmpXJ7gDfESvcJMG7nGQaD8ra8ArdDu2RiomvmL5lb SCOPah/8Hr7JRJBGwuqu2IuzoZ6iEtsNbD8Pbym4KxEM16KJX9PWmAIGUxXICLqVDr 5bs/wF0JzG/Ptvg9v8hBosTXAJyANHjCHeKjAyng= Date: Sat, 7 Jan 2017 09:51:26 +0100 From: Roman Divacky To: Mark Millard Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] Message-ID: <20170107085126.GA82107@vlakno.cz> References: <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 09:02:46 -0000 That's a great progress. Can you produce minimal self contained test case that exhibits this bug? And submit it to llvm bugzilla? Also, clang3.9 defaults to using it's own internal asm, what happens if you add -no-integrated-as to CFLAGS and recompile the kernel? That should remove this llvm assembly problem. Does it boot? Thanks Mark, really great progress. Roman On Thu, Jan 05, 2017 at 09:39:31PM -0800, Mark Millard wrote: > [Summary: I tracked the boot code problem back to clang 3.9.x using R_PPC64_ADDR16_DS > with .toc in locore.o (that does not work) but xtoolchain using R_PPC64_TOC16_DS > with .toc in locore.o (that does work).] > > On 2016-Dec-12, at 1:09 PM, Roman Divacky wrote: > > > Ping.... Can you take a look Nathan? > > > > Thanks! Roman > > > > On Thu, Dec 08, 2016 at 11:14:52PM +0100, Roman Divacky wrote: > >> I believe the code comes from sys/powerpc/aim/locore64.S and if you compare > >> the different values from the disssembly with the .S code you can see > >> it's __tocbase and TOC_REF(). > >> > >> I wonder if the assembly has the -mminimal-toc knowledge hardcoded in somehow. > >> I am not sure what expectations the locore64.S has about the kernel layout that > >> we're probably breaking. > >> > >> I've CCed Nathan Whitehorn. Nathan, can you take a look please? > >> > >> Thanks, Roman > >> > >> On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote: > >>> [I have dropped the patch related information and just have > >>> failing-boot related information here.] > >>> > >>> On 2016-Dec-8, at 10:55 AM, Roman Divacky wrote: > >>> > >>>> Can you try to investigate why it dies? I am not convinced -mminimal-toc > >>>> would result in a boot failure. I think the kernel would fail to link. > >>> > >>> I give information for both devel/powerpc64-binutils based > >>> and for WITH_BINUTILS_BOOTSTRAP= based. They are different. > >>> > >>> For using 2.25.1 of devel/powerpc64-binutils (a cross build): > >>> (from camera image of screen) > >>> > >>> . . . (omitted material) . . . > >>> Type '?' for a list of commands, 'help' for more detailed help. > >>> OK unload > >>> OK boot ker390 > >>> /boot/ker390/kernel data=0xf851a8+0x42dd98 syms=[0x8+0xd6848+0x8+0xf1137] > >>> /boot/entropy size=0x1000 > >>> Booting. . . > >>> Kernel entry at 0x100160 > >>> > >>> Invalid memory access at %SSR0: 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 > >>> 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 > >>> 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 > > Note: > > I discovered with file that the bootstrap binutils and devel/binutils > (and devel/powerpc64-binutils) produce differing types of files: > > bootstrap binutils: sys/GENERIC64vtsc-NODBG/kernel: ELF 64-bit MSB shared object > (only tried with clang) > > devel/*binutils: sys/GENERIC64vtsc-NODBG/kernel: ELF 64-bit MSB executable > (both clang and xtoolchain tried) > > It is the devel/*binutils used with xtoolchain that produces what boots. > > > For the devel/*binutils (with clang vs. xtoolchain) . . . > > > Using objdump on locore.o I see variations based on clang vs. xtoolchain, > including the below relative to .toc handling: > (- -> clang , + -> xtoolchain) > > RELOCATION RECORDS FOR [.text]: > OFFSET TYPE VALUE > . . . > -0000000000000046 R_PPC64_ADDR16_DS .toc > +0000000000000046 R_PPC64_TOC16_DS .toc > . . . > -0000000000000182 R_PPC64_ADDR16_DS .toc > +0000000000000182 R_PPC64_TOC16_DS .toc > . . . > -0000000000000916 R_PPC64_ADDR16_DS .toc > . . . > +0000000000000916 R_PPC64_TOC16_DS .toc > . . . > > In the boot code (/boot/kernel/kernel) these match up with. . . > > Disassembly of section .text: > 0000000000100160 <.__start> mfmsr r20 # clang > vs. > Disassembly of section .text: > 0000000000100120 <.__start> mfmsr r20 # xtoolchain > > . . . > 00000000001001a4 <.__start+0x44> ld r1,0(r2) # 100160+46 clang > vs. > 0000000000100164 <.__start+0x44> ld r1,-32760(r2) # 100120+46 xtoolchain > > . . . > 00000000001002e0 ld r1,0(r2) # 100160+182 clang > vs. > 00000000001002a0 ld r1,-32760(r2) # 100120+182 xtoolchain > > . . . > 0000000000100a74 ld r1,0(r1) # 100160+916 clang > vs. > 0000000000100a34 ld r1,-32760(r1) # 100120+916 xtoolchain > > > > === > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Jan 7 22:07:43 2017 Return-Path: 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 31D08CA4DDE for ; Sat, 7 Jan 2017 22:07:43 +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 D9E1A158B for ; Sat, 7 Jan 2017 22:07:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14587 invoked from network); 7 Jan 2017 22:07:34 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Jan 2017 22:07:34 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sat, 07 Jan 2017 17:07:34 -0500 (EST) Received: (qmail 1168 invoked from network); 7 Jan 2017 22:07:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jan 2017 22:07:34 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id EADD5EC7B24; Sat, 7 Jan 2017 14:07:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: <20170107085126.GA82107@vlakno.cz> Date: Sat, 7 Jan 2017 14:07:33 -0800 Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> References: <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> To: Roman Divacky , Ed Maste X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 22:07:43 -0000 On 2017-Jan-7, at 12:51 AM, Roman Divacky wrote: > That's a great progress. Can you produce minimal self contained test = case that > exhibits this bug? And submit it to llvm bugzilla? >=20 > Also, clang3.9 defaults to using it's own internal asm, what happens = if you > add -no-integrated-as to CFLAGS and recompile the kernel? That should = remove > this llvm assembly problem. Does it boot? >=20 > Thanks Mark, really great progress. >=20 > Roman In attempting this I found how to control the behavior based on the assembler notation @toc being missing vs. being present. If llvm should change is strongly tied to llvm's criteria for gcc compatibility relative to filling-in/defaulting omitted @toc's in the assembler notation. FreeBSD has the option of always being explicit with @toc in order to avoid differences in handling of omitted notation. So I've no clue if FreebSD wants to claim that a llvm change is a requirement for using clang as the powerpc64 system compiler. [The issue of the distinction is submittable to llvm either way.] Details. . . For: .section ".toc","aw" tmpstk.L: .tc tmpstk[TC],tmpstk . . . /* Set up the stack pointer */ ld %r1,tmpstk.L(%r2) using devel/powerpc64-gcc gets: # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = = = locore64_simplified.S locore64_simplified.S: Assembler messages: locore64_simplified.S:80: Warning: assuming @toc on symbol and produces (with R_PPC64_TOC16_DS for .toc): # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o locore64_simplified.o: file format elf64-powerpc-freebsd RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 0000000000000046 R_PPC64_TOC16_DS .toc RELOCATION RECORDS FOR [.toc]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 tmpstk RELOCATION RECORDS FOR [.opd]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 .__start 0000000000000008 R_PPC64_TOC *ABS* By contrast clang is silent (cross compiler used): # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = = = locore64_simplified.S and produces code with R_PPC64_ADDR16_DS for the .toc instead: # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 locore64_simplified.o: file format elf64-powerpc-freebsd RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 0000000000000046 R_PPC64_ADDR16_DS .toc RELOCATION RECORDS FOR [.toc]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 tmpstk RELOCATION RECORDS FOR [.opd]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 .__start 0000000000000008 R_PPC64_TOC *ABS* But for: .section ".toc","aw" tmpstk.L: .tc tmpstk[TC],tmpstk . . . /* Set up the stack pointer */ ld %r1,tmpstk.L@toc(%r2) (note the @toc notation) both compilers agree and use R_PPC64_TOC16_DS for the .toc: # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = = = locore64_simplified.S # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 locore64_simplified.o: file format elf64-powerpc-freebsd RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 0000000000000046 R_PPC64_TOC16_DS .toc RELOCATION RECORDS FOR [.toc]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 tmpstk RELOCATION RECORDS FOR [.opd]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 .__start 0000000000000008 R_PPC64_TOC *ABS* # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = = = locore64_simplified.S # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 locore64_simplified.o: file format elf64-powerpc-freebsd RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 0000000000000046 R_PPC64_TOC16_DS .toc RELOCATION RECORDS FOR [.toc]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 tmpstk RELOCATION RECORDS FOR [.opd]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 .__start 0000000000000008 R_PPC64_TOC *ABS* I omitted "-f -gdwarf-2" to simplify things but with such clang complains about: locore64_simplified.S:36:2: warning: DWARF2 only supports one section = per compilation unit .section ".toc","aw" ^ locore64_simplified.S:47:2: warning: DWARF2 only supports one section = per compilation unit .section ".opd","aw" ^ (buildkernel gets such messages.) I expect I can simplify the .S code more than I have so far but I figured I'd report the discovery of the choice FreeBSD needs to make for powerpc64 for if llvm changes are to be required vs. not. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Jan 7 23:04:04 2017 Return-Path: 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 DFBFECA4458 for ; Sat, 7 Jan 2017 23:04:04 +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 C5D6E1583 for ; Sat, 7 Jan 2017 23:04:04 +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 v07N44hh024977 for ; Sat, 7 Jan 2017 23:04:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc Date: Sat, 07 Jan 2017 23:04:05 +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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 23:04:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215819 --- Comment #3 from Mark Millard --- (In reply to Mark Millard from comment #0) I found how to control the behavior based on the assembler notation @toc being missing vs. being present. If llvm should change is strongly tied to llvm's criteria for gcc compatibility relative to filling-in/defaulting omitted @toc's in the assembler notation. FreeBSD has the option of always being explicit with @toc in order to avoid differences in handling of omitted notation. So I've no clue if FreebSD wants to claim that a llvm change is a requirement for using clang as the powerpc64 system compiler. [The issue of the distinction is submittable to llvm either way.] Details. . . For: .section ".toc","aw" tmpstk.L: .tc tmpstk[TC],tmpstk . . . /* Set up the stack pointer */ ld %r1,tmpstk.L(%r2) using devel/powerpc64-gcc gets: # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 -c \=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -x assembler-with-cpp \=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 -pipe \=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 locore64_simplified.S locore64_simplified.S: Assembler messages: locore64_simplified.S:80: Warning: assuming @toc on symbol and produces (with R_PPC64_TOC16_DS for .toc): # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o locore64_simplified.o: file format elf64-powerpc-freebsd RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 0000000000000046 R_PPC64_TOC16_DS .toc RELOCATION RECORDS FOR [.toc]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 tmpstk RELOCATION RECORDS FOR [.opd]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 .__start 0000000000000008 R_PPC64_TOC *ABS* By contrast clang is silent (cross compiler used): # /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin= /cc \ -target powerpc64-unknown-freebsd12.0 \=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/t= mp \=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin= \=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -c \ -x assembler-with-cpp \=20=20= =20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -pipe \=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 locore64_simplifi= ed.S and produces code with R_PPC64_ADDR16_DS for the .toc instead: # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | more= =20=20=20=20=20=20 locore64_simplified.o: file format elf64-powerpc-freebsd RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 0000000000000046 R_PPC64_ADDR16_DS .toc RELOCATION RECORDS FOR [.toc]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 tmpstk RELOCATION RECORDS FOR [.opd]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 .__start 0000000000000008 R_PPC64_TOC *ABS* But for: .section ".toc","aw" tmpstk.L: .tc tmpstk[TC],tmpstk . . . /* Set up the stack pointer */ ld %r1,tmpstk.L@toc(%r2) (note the @toc notation) both compilers agree and use R_PPC64_TOC16_DS for the .toc: # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 -c \=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -x assembler-with-cpp \=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 -pipe \=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 locore64_simplified.S # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | more= =20=20=20=20=20=20 locore64_simplified.o: file format elf64-powerpc-freebsd RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 0000000000000046 R_PPC64_TOC16_DS .toc RELOCATION RECORDS FOR [.toc]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 tmpstk RELOCATION RECORDS FOR [.opd]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 .__start 0000000000000008 R_PPC64_TOC *ABS* # /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin= /cc \ -target powerpc64-unknown-freebsd12.0 \=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/t= mp \=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin= \=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -c \ -x assembler-with-cpp \=20=20= =20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -pipe \=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 locore64_simplifi= ed.S # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | more= =20=20=20=20=20=20 locore64_simplified.o: file format elf64-powerpc-freebsd RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 0000000000000046 R_PPC64_TOC16_DS .toc RELOCATION RECORDS FOR [.toc]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 tmpstk RELOCATION RECORDS FOR [.opd]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 .__start 0000000000000008 R_PPC64_TOC *ABS* I omitted "-f -gdwarf-2" to simplify things but with such clang complains about: locore64_simplified.S:36:2: warning: DWARF2 only supports one section per compilation unit .section ".toc","aw" ^ locore64_simplified.S:47:2: warning: DWARF2 only supports one section per compilation unit .section ".opd","aw" ^ (buildkernel gets such messages.) I expect I can simplify the .S code more than I have so far but I figured I'd report the discovery of the choice FreeBSD needs to make for powerpc64 for if llvm changes are to be required vs. not. The following should be a list of the places that adding @toc usage would fix things: # grep "@toc[^b]" /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoo= lchain_kernel-amd64-host-2017-01-03:23:48:41 | more /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on symbol /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc on symbol /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc on symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on symbol /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc on symbol --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Jan 7 23:13:04 2017 Return-Path: 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 778EACA472B for ; Sat, 7 Jan 2017 23:13:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-13.reflexion.net [208.70.210.13]) (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 386941A35 for ; Sat, 7 Jan 2017 23:13:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22261 invoked from network); 7 Jan 2017 23:13:02 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Jan 2017 23:13:02 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sat, 07 Jan 2017 18:13:13 -0500 (EST) Received: (qmail 9973 invoked from network); 7 Jan 2017 23:13:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jan 2017 23:13:13 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id A35DBEC900F; Sat, 7 Jan 2017 15:13:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> Date: Sat, 7 Jan 2017 15:12:59 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> To: Roman Divacky , Ed Maste , Justin Hibbits , Nathan Whitehorn X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 23:13:04 -0000 [I've supplied a list of places that adding @toc notation should make clang 3.9.1 targeting powerpc64 do the right thing for this issue.] On 2017-Jan-7, at 2:07 PM, Mark Millard wrote: > On 2017-Jan-7, at 12:51 AM, Roman Divacky = wrote: >=20 >> That's a great progress. Can you produce minimal self contained test = case that >> exhibits this bug? And submit it to llvm bugzilla? >>=20 >> Also, clang3.9 defaults to using it's own internal asm, what happens = if you >> add -no-integrated-as to CFLAGS and recompile the kernel? That should = remove >> this llvm assembly problem. Does it boot? >>=20 >> Thanks Mark, really great progress. >>=20 >> Roman >=20 > In attempting this I found how to control the behavior based on > the assembler notation @toc being missing vs. being present. >=20 > If llvm should change is strongly tied to llvm's criteria for > gcc compatibility relative to filling-in/defaulting omitted > @toc's in the assembler notation. >=20 > FreeBSD has the option of always being explicit with @toc in order > to avoid differences in handling of omitted notation. >=20 > So I've no clue if FreebSD wants to claim that a llvm change > is a requirement for using clang as the powerpc64 system compiler. >=20 > [The issue of the distinction is submittable to llvm either way.] >=20 > Details. . . >=20 > For: >=20 > .section ".toc","aw" > tmpstk.L: .tc tmpstk[TC],tmpstk > . . . > /* Set up the stack pointer */ > ld %r1,tmpstk.L(%r2) >=20 > using devel/powerpc64-gcc gets: >=20 > # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 > = locore64_simplified.S > locore64_simplified.S: Assembler messages: > locore64_simplified.S:80: Warning: assuming @toc on symbol >=20 > and produces (with R_PPC64_TOC16_DS for .toc): >=20 > # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o >=20 > locore64_simplified.o: file format elf64-powerpc-freebsd >=20 > RELOCATION RECORDS FOR [.text]: > OFFSET TYPE VALUE=20 > 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > 0000000000000046 R_PPC64_TOC16_DS .toc >=20 >=20 > RELOCATION RECORDS FOR [.toc]: > OFFSET TYPE VALUE=20 > 0000000000000000 R_PPC64_ADDR64 tmpstk >=20 >=20 > RELOCATION RECORDS FOR [.opd]: > OFFSET TYPE VALUE=20 > 0000000000000000 R_PPC64_ADDR64 .__start > 0000000000000008 R_PPC64_TOC *ABS* >=20 >=20 > By contrast clang is silent (cross compiler used): >=20 > # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 > = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >=20 > and produces code with R_PPC64_ADDR16_DS for the .toc instead: >=20 > # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 > locore64_simplified.o: file format elf64-powerpc-freebsd >=20 > RELOCATION RECORDS FOR [.text]: > OFFSET TYPE VALUE=20 > 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > 0000000000000046 R_PPC64_ADDR16_DS .toc >=20 >=20 > RELOCATION RECORDS FOR [.toc]: > OFFSET TYPE VALUE=20 > 0000000000000000 R_PPC64_ADDR64 tmpstk >=20 >=20 > RELOCATION RECORDS FOR [.opd]: > OFFSET TYPE VALUE=20 > 0000000000000000 R_PPC64_ADDR64 .__start > 0000000000000008 R_PPC64_TOC *ABS* >=20 >=20 >=20 > But for: >=20 > .section ".toc","aw" > tmpstk.L: .tc tmpstk[TC],tmpstk > . . . > /* Set up the stack pointer */ > ld %r1,tmpstk.L@toc(%r2) >=20 > (note the @toc notation) both compilers agree and use > R_PPC64_TOC16_DS for the .toc: >=20 > # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 > = locore64_simplified.S >=20 > # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 > locore64_simplified.o: file format elf64-powerpc-freebsd >=20 > RELOCATION RECORDS FOR [.text]: > OFFSET TYPE VALUE=20 > 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > 0000000000000046 R_PPC64_TOC16_DS .toc >=20 >=20 > RELOCATION RECORDS FOR [.toc]: > OFFSET TYPE VALUE=20 > 0000000000000000 R_PPC64_ADDR64 tmpstk >=20 >=20 > RELOCATION RECORDS FOR [.opd]: > OFFSET TYPE VALUE=20 > 0000000000000000 R_PPC64_ADDR64 .__start > 0000000000000008 R_PPC64_TOC *ABS* >=20 >=20 > # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 > = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >=20 > # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 > locore64_simplified.o: file format elf64-powerpc-freebsd >=20 > RELOCATION RECORDS FOR [.text]: > OFFSET TYPE VALUE=20 > 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > 0000000000000046 R_PPC64_TOC16_DS .toc >=20 >=20 > RELOCATION RECORDS FOR [.toc]: > OFFSET TYPE VALUE=20 > 0000000000000000 R_PPC64_ADDR64 tmpstk >=20 >=20 > RELOCATION RECORDS FOR [.opd]: > OFFSET TYPE VALUE=20 > 0000000000000000 R_PPC64_ADDR64 .__start > 0000000000000008 R_PPC64_TOC *ABS* >=20 >=20 >=20 > I omitted "-f -gdwarf-2" to simplify things but with such > clang complains about: >=20 > locore64_simplified.S:36:2: warning: DWARF2 only supports one section = per compilation unit > .section ".toc","aw" > ^ > locore64_simplified.S:47:2: warning: DWARF2 only supports one section = per compilation unit > .section ".opd","aw" > ^ >=20 > (buildkernel gets such messages.) >=20 >=20 > I expect I can simplify the .S code more than I have so far but > I figured I'd report the discovery of the choice FreeBSD needs > to make for powerpc64 for if llvm changes are to be required > vs. not. The following should be a list of the places that adding @toc usage would fix some things for using clang 3.9.1 to target powerpc64: # grep "@toc[^b]" = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain_kernel-amd64-host-2017-01-03:23:48:41 | more /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on = symbol /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc on = symbol /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc on = symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on = symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on = symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on = symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on = symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on = symbol /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on = symbol /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc on = symbol devel/powerpc64-gcc and devel/powerpc64-binutils together happens to = report on missing @toc 's. But, of course, if some sections of code are conditionally compiled and excluded above they would not be listed. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Jan 7 23:57:52 2017 Return-Path: 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 48698CA49D2 for ; Sat, 7 Jan 2017 23:57: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 372D412F6 for ; Sat, 7 Jan 2017 23:57: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 v07NvqwE034920 for ; Sat, 7 Jan 2017 23:57:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc Date: Sat, 07 Jan 2017 23:57: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: 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 23:57:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215819 --- Comment #4 from Mark Millard --- (In reply to Mark Millard from comment #2) The following locore64_simplified.S source code is sufficient to show the silent R_PPC64_ADDR16_DS generation problem: .align 4 .data .p2align 2 .globl tmpstk tmpstk: .space 16384 .section ".toc","aw" tmpstk.L: .tc tmpstk[TC],tmpstk .text ld %r1,tmpstk.L(%r2) # /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin= /cc \=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -target powerpc64-unknown-freebsd12.0 \= =20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/t= mp \=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin= \=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -c \=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -x assembler-with-cpp \=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 -pipe \=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 locore64_simplified.S # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | more= =20=20=20=20=20=20 locore64_simplified.o: file format elf64-powerpc-freebsd RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 0000000000000002 R_PPC64_ADDR16_DS .toc RELOCATION RECORDS FOR [.toc]: OFFSET TYPE VALUE=20 0000000000000000 R_PPC64_ADDR64 tmpstk --=20 You are receiving this mail because: You are the assignee for the bug.=