From owner-freebsd-toolchain@freebsd.org Sun May 7 00:21:13 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 15472D5551F for ; Sun, 7 May 2017 00:21:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-77.reflexion.net [208.70.210.77]) (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 990EB1723 for ; Sun, 7 May 2017 00:21:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2829 invoked from network); 7 May 2017 00:21:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 May 2017 00:21:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 06 May 2017 20:21:10 -0400 (EDT) Received: (qmail 8232 invoked from network); 7 May 2017 00:21:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 May 2017 00:21:10 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8B20FEC808D; Sat, 6 May 2017 17:21:09 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" Message-Id: Date: Sat, 6 May 2017 17:21:08 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Ports X-Mailer: Apple Mail (2.3273) 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, 07 May 2017 00:21:13 -0000 On: # uname -apKU FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc = powerpc 1200030 1200030 When I attempt to use: # which kgdb /usr/local/bin/kgdb that was from building devel/gdb for: # svnlite info /usr/ports | grep "Re[plv]" Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 440115 Last Changed Rev: 440115 (built via gcc 4.2.1: not via clang: I experiment with clang for powerpc and powerpc64 so I'm being explicit) I end up getting the following sort of result: # kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.4=20 . . . Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done. ABI doesn't support a vmcore target That message is from: /usr/ports/devel/gdb/files/kgdb/fbsd-kvm.c . . . static void kgdb_trgt_open(const char *arg, int from_tty) { struct fbsd_vmcore_ops *ops =3D (struct fbsd_vmcore_ops *) gdbarch_data (target_gdbarch(), fbsd_vmcore_data); . . . if (ops =3D=3D NULL || ops->supply_pcb =3D=3D NULL || = ops->cpu_pcb_addr =3D=3D NULL) error ("ABI doesn't support a vmcore target"); . . . It appears that there is no kernel debugging supported for TARGET_ARCH=3Dpowerpc currently. (The system no longer has its own gdb related materials.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun May 7 01:53: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 1EB9DD5F505 for ; Sun, 7 May 2017 01:53:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-78.reflexion.net [208.70.210.78]) (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 C2E28152 for ; Sun, 7 May 2017 01:53:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11182 invoked from network); 7 May 2017 01:53:34 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 May 2017 01:53:34 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 06 May 2017 21:53:34 -0400 (EDT) Received: (qmail 11141 invoked from network); 7 May 2017 01:53:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 May 2017 01:53:34 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E3711EC808D; Sat, 6 May 2017 18:53:33 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Panics for gcc-4.2.1-based powerpc non-debug head kernel builds (e.g., -r317820); no powerpc kernel debugger support (system or ports) Message-Id: Date: Sat, 6 May 2017 18:53:33 -0700 Cc: FreeBSD Toolchain To: FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) 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, 07 May 2017 01:53:43 -0000 [I'm forking off this subject from the llvm bugzilla 26519's latest partial TARET_ARCH=3Dpowerpc fix material as it seems to be independent.] I've recently been building, installing, and using TARGET_ARCH=3Dpowerpc again (because of a partial clang fix for targeting powerpc 32-bit). But the context here can be restricted to just gcc 4.2.1 based builds/installs (world and kernel), head -r317820 most recent tried. [It has been a long time since I'd last built for TARGET_ARCH=3Dpowerpc.] When I run from a debug kernel there has been no observed problems. But running from a production kernel I get occasional panics for "unknown" exceptions. I have cleared out (rm -fr) and rebuilt and reinstalled in case of corruptions, it has not made a difference. I'll note that the same machine does fine with TARGET_ARCH=3Dpowerpc64 builds (system-clang based normally for me). So far all the powerpc panics report: pid=3D11, comm=3Didle: CPU In other words: the [idle{idle: cpu}] threads. Things are unusual in various respects, such as an lr figure that is odd, like 0x907f and exception numbers that are classified as "(unknown)", for example for the number: 0x903a64e . No stack trace is produced. Nearly all the reports claim ffs_truncate+0x1080 for where but I have recently seen something else as well (not recorded, unfortunately). But I'm not sure I'd trust that aspect of the report. Unfortunately calling doadump is not all that useful. Using core.text. to illustrate: # grep unsupported /var/crash/core.txt.5 | more Failed to open vmcore: unsupported architecture ps: unsupported architecture vmstat: kvm_openfiles: unsupported architecture vmstat: kvm_openfiles: unsupported architecture vmstat: kvm_openfiles: unsupported architecture vmstat: kvm_openfiles: unsupported architecture pstat: kvm_openfiles: unsupported architecture pstat: kvm_openfiles: unsupported architecture iostat: kvm_openfiles: unsupported architecture ipcs: kvm_openfiles: unsupported architecture ipcs: kvm_openfiles: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture fstat: kvm_openfiles(): unsupported architecture dmesg: unsupported architecture ddb: ddb_capture: kvm_openfiles: unsupported architecture Only the kernel config section is filled in for core.txt.5 (or the others). And kgdb from devel/gdb (-r440115 of /usr/ports) reports: # kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.5=20 . . . Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done. ABI doesn't support a vmcore target By contrast with a debug kernel I was able to do buildworld buildkernel from scratch to completion and leave it sit idle for much longer than it has stayed up idle for the production kernel. (The panics are not normally frequent so this takes a while.) If I have a clang based world mixed with the gcc 4.2.1 kernels the same things apply but for powerpc at this point the better context is to stick to just gcc 4.2.1 based builds. The powerpc machine is a old PowerMac. # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/sys/arm/arm/gic.h M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk (The Makefile* and *.mk stuff is historical from being compatible with both system and xtoolchain based activity.) I build with both sc and vt but normally use sc via /boot/loader.conf : # more /boot/loader.conf=20 kernel=3D"kernel" verbose_loading=3D"YES" kern.vty=3Dsc dumpdev=3D"/dev/label/FBSDG4Sswap" # more /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG # # GENERIC -- Custom configuration for the powerpc/powerpc # include "GENERIC" ident GENERICvtsc-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger options GDB # HACK!!! ... # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones I normally run a amd64 -> powerpc cross build, in this case via gcc 4.2.1 : # more ~/src.configs/src.conf.powerpc-gcc421-bootstrap-clang.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 # WITHOUT_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG_FULL=3D WITHOUT_CLANG_EXTRAS=3D WITHOUT_LLD=3D WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITH_GCC_IS_CC=3D WITH_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D The amd64 context is also head -r317820 currently. Right now it looks fairly difficult to get a clue about what might be at issue for these panics. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun May 7 05:04:03 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 051B5D626BB for ; Sun, 7 May 2017 05:04:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-77.reflexion.net [208.70.210.77]) (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 A25E11462 for ; Sun, 7 May 2017 05:04:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32249 invoked from network); 7 May 2017 05:03:59 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 May 2017 05:03:59 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 07 May 2017 01:03:59 -0400 (EDT) Received: (qmail 6106 invoked from network); 7 May 2017 05:03:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 May 2017 05:03:59 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6FC5FEC8F8E; Sat, 6 May 2017 22:03:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" From: Mark Millard In-Reply-To: Date: Sat, 6 May 2017 22:03:57 -0700 Cc: FreeBSD Ports , andreast@FreeBSD.org, John Baldwin Content-Transfer-Encoding: quoted-printable Message-Id: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> References: To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) 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, 07 May 2017 05:04:03 -0000 On 2017-May-6, at 5:21 PM, Mark Millard wrote: > On: >=20 > # uname -apKU > FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc = powerpc 1200030 1200030 >=20 > When I attempt to use: >=20 > # which kgdb > /usr/local/bin/kgdb >=20 > that was from building devel/gdb for: >=20 > # svnlite info /usr/ports | grep "Re[plv]" > Relative URL: ^/head > Repository Root: https://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 440115 > Last Changed Rev: 440115 >=20 > (built via gcc 4.2.1: not via clang: I > experiment with clang for powerpc and > powerpc64 so I'm being explicit) >=20 > I end up getting the following sort of result: >=20 > # kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.4=20 > . . . > Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done. > ABI doesn't support a vmcore target >=20 > That message is from: /usr/ports/devel/gdb/files/kgdb/fbsd-kvm.c . . . >=20 > static void > kgdb_trgt_open(const char *arg, int from_tty) > { > struct fbsd_vmcore_ops *ops =3D (struct fbsd_vmcore_ops *) > gdbarch_data (target_gdbarch(), fbsd_vmcore_data); > . . . > if (ops =3D=3D NULL || ops->supply_pcb =3D=3D NULL || = ops->cpu_pcb_addr =3D=3D NULL) > error ("ABI doesn't support a vmcore target"); > . . . >=20 > It appears that there is no kernel debugging > supported for TARGET_ARCH=3Dpowerpc currently. > (The system no longer has its own gdb related > materials.) I've discovered more context and have found a few of issues in how things are currently set up. THING #0: It appears that usr.sbin/crashinfo/crashinfo.sh assumes that /usr/local/bin/gdb will work better for all architectures, including for kgdb types of activity: find_gdb() { local binary for binary in /usr/local/bin/gdb /usr/libexec/gdb /usr/bin/gdb; = do if [ -x ${binary} ]; then GDB=3D${binary} return fi done } But it appears that on powerpc /usr/local/bin/gdb and /usr/local/bin/kgdb do not support TARGET_ARCH=3Dpowerpc at all for such activity. THING #1: Another oddity is for the combination: ${MK_GDB} =3D=3D no && ${MK_GDB_LIBEXEC} =3D=3D yes where the tools/build/mk/OptionalObsoleteFiles.inc logic then adds the libexec gdb and kgdb to OLD_FILES : .if ${MK_GDB} =3D=3D no || ${MK_GDB_LIBEXEC} =3D=3D no OLD_FILES+=3Dusr/libexec/gdb OLD_FILES+=3Dusr/libexec/kgdb .endif so doing a delete-old removes the only system gdb and kgdb that are installed for such a context. It does this because of: ${MK_GDB} =3D=3D no (And that explains why I thought gdb and kgdb were not in the system.) THING #2: /usr/libexec/kgdb (when present) does not support the powerpc architecture for head either . . . On a head -r317820 powerpc I attempted: # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.7 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "powerpc-marcel-freebsd"... Failed to open vmcore: unsupported architecture =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun May 7 19:21: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 1D066D62789 for ; Sun, 7 May 2017 19:21:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-77.reflexion.net [208.70.210.77]) (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 C04F515F5 for ; Sun, 7 May 2017 19:21:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26197 invoked from network); 7 May 2017 19:21:37 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 May 2017 19:21:37 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 07 May 2017 15:21:37 -0400 (EDT) Received: (qmail 20447 invoked from network); 7 May 2017 19:21:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 May 2017 19:21:37 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3452AEC8809; Sun, 7 May 2017 12:21:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" From: Mark Millard In-Reply-To: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> Date: Sun, 7 May 2017 12:21:35 -0700 Cc: FreeBSD Ports , andreast@FreeBSD.org, John Baldwin Content-Transfer-Encoding: quoted-printable Message-Id: <540903B2-A752-49D9-9833-42C7AC87089F@dsl-only.net> References: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) 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, 07 May 2017 19:21:45 -0000 [This update just notes that it appears that combination ${MK_GDB} =3D=3D no && ${MK_GDB_LIBEXEC} =3D=3D yes is not intended to be used, effectively eliminating "THING #1" of 0-2.] On 2017-May-6, at 10:03 PM, Mark Millard wrote: > On 2017-May-6, at 5:21 PM, Mark Millard = wrote: >=20 >> On: >>=20 >> # uname -apKU >> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc = powerpc 1200030 1200030 >>=20 >> When I attempt to use: >>=20 >> # which kgdb >> /usr/local/bin/kgdb >>=20 >> that was from building devel/gdb for: >>=20 >> # svnlite info /usr/ports | grep "Re[plv]" >> Relative URL: ^/head >> Repository Root: https://svn.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 440115 >> Last Changed Rev: 440115 >>=20 >> (built via gcc 4.2.1: not via clang: I >> experiment with clang for powerpc and >> powerpc64 so I'm being explicit) >>=20 >> I end up getting the following sort of result: >>=20 >> # kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.4=20 >> . . . >> Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done. >> ABI doesn't support a vmcore target >>=20 >> That message is from: /usr/ports/devel/gdb/files/kgdb/fbsd-kvm.c . . = . >>=20 >> static void >> kgdb_trgt_open(const char *arg, int from_tty) >> { >> struct fbsd_vmcore_ops *ops =3D (struct fbsd_vmcore_ops *) >> gdbarch_data (target_gdbarch(), fbsd_vmcore_data); >> . . . >> if (ops =3D=3D NULL || ops->supply_pcb =3D=3D NULL || = ops->cpu_pcb_addr =3D=3D NULL) >> error ("ABI doesn't support a vmcore target"); >> . . . >>=20 >> It appears that there is no kernel debugging >> supported for TARGET_ARCH=3Dpowerpc currently. >> (The system no longer has its own gdb related >> materials.) >=20 > I've discovered more context and have found > a few of issues in how things are currently > set up. >=20 > THING #0: >=20 > It appears that usr.sbin/crashinfo/crashinfo.sh assumes > that /usr/local/bin/gdb will work better for all architectures, > including for kgdb types of activity: >=20 > find_gdb() > { > local binary >=20 > for binary in /usr/local/bin/gdb /usr/libexec/gdb /usr/bin/gdb; = do > if [ -x ${binary} ]; then > GDB=3D${binary} > return > fi > done > } >=20 > But it appears that on powerpc /usr/local/bin/gdb and > /usr/local/bin/kgdb do not support TARGET_ARCH=3Dpowerpc > at all for such activity. >=20 >=20 > THING #1: >=20 > Another oddity is for the combination: >=20 > ${MK_GDB} =3D=3D no && ${MK_GDB_LIBEXEC} =3D=3D yes >=20 > where the tools/build/mk/OptionalObsoleteFiles.inc > logic then adds the libexec gdb and kgdb to > OLD_FILES : >=20 > .if ${MK_GDB} =3D=3D no || ${MK_GDB_LIBEXEC} =3D=3D no > OLD_FILES+=3Dusr/libexec/gdb > OLD_FILES+=3Dusr/libexec/kgdb > .endif >=20 > so doing a delete-old removes the only system > gdb and kgdb that are installed for such a > context. It does this because of: >=20 > ${MK_GDB} =3D=3D no >=20 > (And that explains why I thought gdb and kgdb > were not in the system.) Looking around at how WITH_GDB and WITH_GDB_LIBEXEC and the MK_ variants are used it appears that the: ${MK_GDB} =3D=3D no && ${MK_GDB_LIBEXEC} =3D=3D yes combination is not intended to be used. > THING #2: >=20 > /usr/libexec/kgdb (when present) does not support the > powerpc architecture for head either . . . >=20 > On a head -r317820 powerpc I attempted: >=20 > # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.7 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and = you are > welcome to change it and/or distribute copies of it under certain = conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for = details. > This GDB was configured as "powerpc-marcel-freebsd"... > Failed to open vmcore: unsupported architecture =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon May 8 19:06: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 2E9DCD63A11; Mon, 8 May 2017 19:06:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (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 5B5D017A2; Mon, 8 May 2017 19:06:26 +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 5BE7A10A7B9; Mon, 8 May 2017 15:06:18 -0400 (EDT) From: John Baldwin To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Ports , andreast@freebsd.org Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" Date: Mon, 08 May 2017 11:30:53 -0700 Message-ID: <2567165.qjEVz8HF8R@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> References: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> 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, 08 May 2017 15:06:18 -0400 (EDT) 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, 08 May 2017 19:06:27 -0000 On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote: > THING #0: > > It appears that usr.sbin/crashinfo/crashinfo.sh assumes > that /usr/local/bin/gdb will work better for all architectures, > including for kgdb types of activity: > > find_gdb() > { > local binary > > for binary in /usr/local/bin/gdb /usr/libexec/gdb /usr/bin/gdb; do > if [ -x ${binary} ]; then > GDB=${binary} > return > fi > done > } > > But it appears that on powerpc /usr/local/bin/gdb and > /usr/local/bin/kgdb do not support TARGET_ARCH=powerpc > at all for such activity. Not really. kgdb on powerpc doesn't work period as neither the base nor ports kgdb can unwind a stack frame. I spent some time last year trying to get the unwind out of cpu_switch() to work to no avail. The current hack attempts are here: https://github.com/bsdjhb/gdb/compare/freebsd-7.11-kgdb...kgdb-ppc > THING #1: > > Another oddity is for the combination: > > ${MK_GDB} == no && ${MK_GDB_LIBEXEC} == yes As I think you figured out, MK_GDB_LIBEXEC depends on MK_GDB=yes. If WITHOUT_GDB=yes is set, then no "base" GDB is installed at all. WITH_GDB_LIBEXEC is just to decide in the MK_GDB=yes case where "base" GDB goes: /usr/bin vs /usr/libexec. > THING #2: > > /usr/libexec/kgdb (when present) does not support the > powerpc architecture for head either . . . > > On a head -r317820 powerpc I attempted: > > # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.7 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "powerpc-marcel-freebsd"... > Failed to open vmcore: unsupported architecture This is a different problem with libkvm. I would start with 'ps -M' and use a debugger to step through the _powerpc_probe and _powerpc64_probe routines in libkvm to see why the appropriate probe routine isn't claiming the core. -- John Baldwin From owner-freebsd-toolchain@freebsd.org Mon May 8 20:45:05 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 EE5A0D6351B for ; Mon, 8 May 2017 20:45:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-91.reflexion.net [208.70.210.91]) (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 A9FE91E15 for ; Mon, 8 May 2017 20:45:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21123 invoked from network); 8 May 2017 20:18:24 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 8 May 2017 20:18:24 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 08 May 2017 16:18:24 -0400 (EDT) Received: (qmail 21383 invoked from network); 8 May 2017 20:18:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 May 2017 20:18:23 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 57C0BEC881F; Mon, 8 May 2017 13:18:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" From: Mark Millard In-Reply-To: <2567165.qjEVz8HF8R@ralph.baldwin.cx> Date: Mon, 8 May 2017 13:18:21 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Ports , andreast@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3A7CC677-0946-4BF3-8622-530BF274605F@dsl-only.net> References: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> <2567165.qjEVz8HF8R@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3273) 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, 08 May 2017 20:45:06 -0000 [Mostly: Why THING #2 fails: checks for ET_EXEC but the actual vmcore.* 's have ET_DYN instead.] On 2017-May-8, at 11:30 AM, John Baldwin wrote: > On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote: >> THING #0: >>=20 >> It appears that usr.sbin/crashinfo/crashinfo.sh assumes >> that /usr/local/bin/gdb will work better for all architectures, >> including for kgdb types of activity: >>=20 >> find_gdb() >> { >> local binary >>=20 >> for binary in /usr/local/bin/gdb /usr/libexec/gdb = /usr/bin/gdb; do >> if [ -x ${binary} ]; then >> GDB=3D${binary} >> return >> fi >> done >> } >>=20 >> But it appears that on powerpc /usr/local/bin/gdb and >> /usr/local/bin/kgdb do not support TARGET_ARCH=3Dpowerpc >> at all for such activity. >=20 > Not really. kgdb on powerpc doesn't work period as neither the base = nor ports > kgdb can unwind a stack frame. I spent some time last year trying to = get the > unwind out of cpu_switch() to work to no avail. The current hack = attempts are > here: >=20 > https://github.com/bsdjhb/gdb/compare/freebsd-7.11-kgdb...kgdb-ppc Interesting. >> THING #1: >> . . . >=20 >> THING #2: >>=20 >> /usr/libexec/kgdb (when present) does not support the >> powerpc architecture for head either . . . >>=20 >> On a head -r317820 powerpc I attempted: >>=20 >> # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.7 >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and = you are >> welcome to change it and/or distribute copies of it under certain = conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for = details. >> This GDB was configured as "powerpc-marcel-freebsd"... >> Failed to open vmcore: unsupported architecture >=20 > This is a different problem with libkvm. I would start with 'ps -M' = and use > a debugger to step through the _powerpc_probe and _powerpc64_probe = routines in > libkvm to see why the appropriate probe routine isn't claiming the = core. For THING #2: I had to use /usr/libexec/gdb as the debugger because /usr/local/bin/gdb segmentation faulted. (gdb) list 126 int 127 _kvm_probe_elf_kernel(kvm_t *kd, int class, int machine) 128 { 129=09 130 return (kd->nlehdr.e_ident[EI_CLASS] =3D=3D class && 131 kd->nlehdr.e_type =3D=3D ET_EXEC && 132 kd->nlehdr.e_machine =3D=3D machine); 133 } gets false via: kd->nlehdr.e_type =3D=3D ET_EXEC (gdb) print kd->nlehdr.e_type $4 =3D 3 but the comparison is for: 0x41882fe0 <_kvm_probe_elf_kernel+32>: cmplwi cr1,r4,2 (gdb) disass Dump of assembler code for function _kvm_probe_elf_kernel: 0x41882fc0 <_kvm_probe_elf_kernel+0>: stwu r1,-16(r1) 0x41882fc4 <_kvm_probe_elf_kernel+4>: stw r31,12(r1) 0x41882fc8 <_kvm_probe_elf_kernel+8>: mr r31,r1 0x41882fcc <_kvm_probe_elf_kernel+12>: lbz r6,2076(r3) 0x41882fd0 <_kvm_probe_elf_kernel+16>: crclr eq 0x41882fd4 <_kvm_probe_elf_kernel+20>: cmplw cr1,r6,r4 0x41882fd8 <_kvm_probe_elf_kernel+24>: bne- cr1,0x41882ff0 = <_kvm_probe_elf_kernel+48> 0x41882fdc <_kvm_probe_elf_kernel+28>: lhz r4,2088(r3) 0x41882fe0 <_kvm_probe_elf_kernel+32>: cmplwi cr1,r4,2 0x41882fe4 <_kvm_probe_elf_kernel+36>: bne- cr1,0x41882ff0 = <_kvm_probe_elf_kernel+48> 0x41882fe8 <_kvm_probe_elf_kernel+40>: lhz r3,2090(r3) 0x41882fec <_kvm_probe_elf_kernel+44>: cmpw r3,r5 0x41882ff0 <_kvm_probe_elf_kernel+48>: li r3,1 0x41882ff4 <_kvm_probe_elf_kernel+52>: beq- 0x41882ffc = <_kvm_probe_elf_kernel+60> 0x41882ff8 <_kvm_probe_elf_kernel+56>: li r3,0 0x41882ffc <_kvm_probe_elf_kernel+60>: lwz r31,12(r1) 0x41883000 <_kvm_probe_elf_kernel+64>: addi r1,r1,16 0x41883004 <_kvm_probe_elf_kernel+68>: blr powerpc and powerpc64 use position independent kernels these days as I remember, making kd->nlehdr.e_type be ET_DYN instead of ET_EXEC : /* e_type */ #define ET_REL 1 #define ET_EXEC 2 #define ET_DYN 3 #define ET_CORE 4 I do not know if more needs to change than just the enabling test since the content is ET_DYN type of material. It looks like the conversion to position independent kernels for powerpc and powerpc64 did not cover all the related infrastructure, such as libkvm. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon May 8 21:36: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 88CD8D64400 for ; Mon, 8 May 2017 21:36:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 39CFE959 for ; Mon, 8 May 2017 21:36:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22655 invoked from network); 8 May 2017 21:38:06 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 May 2017 21:38:06 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 08 May 2017 17:36:55 -0400 (EDT) Received: (qmail 9323 invoked from network); 8 May 2017 21:36:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 May 2017 21:36:55 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B702CEC9220; Mon, 8 May 2017 14:36:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" From: Mark Millard In-Reply-To: <3A7CC677-0946-4BF3-8622-530BF274605F@dsl-only.net> Date: Mon, 8 May 2017 14:36:54 -0700 Cc: FreeBSD Toolchain , andreast@freebsd.org, FreeBSD Ports , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <599466E6-DDFB-4C94-B16D-B0F5CA787431@dsl-only.net> References: <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> <2567165.qjEVz8HF8R@ralph.baldwin.cx> <3A7CC677-0946-4BF3-8622-530BF274605F@dsl-only.net> To: John Baldwin X-Mailer: Apple Mail (2.3273) 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, 08 May 2017 21:36:57 -0000 [I've submitted bugzilla 219153 for this libvm issue of not handling powerpc's/powerp64's ET_DYN vmcore.* 's and such.] On 2017-May-8, at 1:18 PM, Mark Millard wrote: > [Mostly: Why THING #2 fails: checks for ET_EXEC > but the actual vmcore.* 's have ET_DYN instead.] >=20 > On 2017-May-8, at 11:30 AM, John Baldwin wrote: >=20 >> On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote: >>> THING #0: >>>=20 >>> It appears that usr.sbin/crashinfo/crashinfo.sh assumes >>> that /usr/local/bin/gdb will work better for all architectures, >>> including for kgdb types of activity: >>>=20 >>> find_gdb() >>> { >>> local binary >>>=20 >>> for binary in /usr/local/bin/gdb /usr/libexec/gdb = /usr/bin/gdb; do >>> if [ -x ${binary} ]; then >>> GDB=3D${binary} >>> return >>> fi >>> done >>> } >>>=20 >>> But it appears that on powerpc /usr/local/bin/gdb and >>> /usr/local/bin/kgdb do not support TARGET_ARCH=3Dpowerpc >>> at all for such activity. >>=20 >> Not really. kgdb on powerpc doesn't work period as neither the base = nor ports >> kgdb can unwind a stack frame. I spent some time last year trying to = get the >> unwind out of cpu_switch() to work to no avail. The current hack = attempts are >> here: >>=20 >> https://github.com/bsdjhb/gdb/compare/freebsd-7.11-kgdb...kgdb-ppc >=20 > Interesting. >=20 >>> THING #1: >>> . . . >>=20 >>> THING #2: >>>=20 >>> /usr/libexec/kgdb (when present) does not support the >>> powerpc architecture for head either . . . >>>=20 >>> On a head -r317820 powerpc I attempted: >>>=20 >>> # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.7 >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and = you are >>> welcome to change it and/or distribute copies of it under certain = conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for = details. >>> This GDB was configured as "powerpc-marcel-freebsd"... >>> Failed to open vmcore: unsupported architecture >>=20 >> This is a different problem with libkvm. I would start with 'ps -M' = and use >> a debugger to step through the _powerpc_probe and _powerpc64_probe = routines in >> libkvm to see why the appropriate probe routine isn't claiming the = core. >=20 > For THING #2: >=20 > I had to use /usr/libexec/gdb as the debugger because = /usr/local/bin/gdb > segmentation faulted. >=20 > (gdb) list > 126 int > 127 _kvm_probe_elf_kernel(kvm_t *kd, int class, int machine) > 128 { > 129=09 > 130 return (kd->nlehdr.e_ident[EI_CLASS] =3D=3D class && > 131 kd->nlehdr.e_type =3D=3D ET_EXEC && > 132 kd->nlehdr.e_machine =3D=3D machine); > 133 } >=20 > gets false via: kd->nlehdr.e_type =3D=3D ET_EXEC >=20 > (gdb) print kd->nlehdr.e_type > $4 =3D 3 >=20 > but the comparison is for: >=20 > 0x41882fe0 <_kvm_probe_elf_kernel+32>: cmplwi cr1,r4,2 >=20 > (gdb) disass > Dump of assembler code for function _kvm_probe_elf_kernel: > 0x41882fc0 <_kvm_probe_elf_kernel+0>: stwu r1,-16(r1) > 0x41882fc4 <_kvm_probe_elf_kernel+4>: stw r31,12(r1) > 0x41882fc8 <_kvm_probe_elf_kernel+8>: mr r31,r1 > 0x41882fcc <_kvm_probe_elf_kernel+12>: lbz r6,2076(r3) > 0x41882fd0 <_kvm_probe_elf_kernel+16>: crclr eq > 0x41882fd4 <_kvm_probe_elf_kernel+20>: cmplw cr1,r6,r4 > 0x41882fd8 <_kvm_probe_elf_kernel+24>: bne- cr1,0x41882ff0 = <_kvm_probe_elf_kernel+48> > 0x41882fdc <_kvm_probe_elf_kernel+28>: lhz r4,2088(r3) > 0x41882fe0 <_kvm_probe_elf_kernel+32>: cmplwi cr1,r4,2 > 0x41882fe4 <_kvm_probe_elf_kernel+36>: bne- cr1,0x41882ff0 = <_kvm_probe_elf_kernel+48> > 0x41882fe8 <_kvm_probe_elf_kernel+40>: lhz r3,2090(r3) > 0x41882fec <_kvm_probe_elf_kernel+44>: cmpw r3,r5 > 0x41882ff0 <_kvm_probe_elf_kernel+48>: li r3,1 > 0x41882ff4 <_kvm_probe_elf_kernel+52>: beq- 0x41882ffc = <_kvm_probe_elf_kernel+60> > 0x41882ff8 <_kvm_probe_elf_kernel+56>: li r3,0 > 0x41882ffc <_kvm_probe_elf_kernel+60>: lwz r31,12(r1) > 0x41883000 <_kvm_probe_elf_kernel+64>: addi r1,r1,16 > 0x41883004 <_kvm_probe_elf_kernel+68>: blr >=20 > powerpc and powerpc64 use position independent kernels > these days as I remember, making kd->nlehdr.e_type be > ET_DYN instead of ET_EXEC : >=20 > /* e_type */ > #define ET_REL 1 > #define ET_EXEC 2 > #define ET_DYN 3 > #define ET_CORE 4 >=20 > I do not know if more needs to change than just > the enabling test since the content is ET_DYN > type of material. >=20 > It looks like the conversion to position independent > kernels for powerpc and powerpc64 did not cover all > the related infrastructure, such as libkvm. I've submitted bugzilla 219153 for this libvm issue of not handling powerpc's/powerp64's ET_DYN vmcore.* 's and such. It applies to head , stable/11 , and release/11.0.1 : 20150307: The 32-bit PowerPC kernel has been changed to a = position-independent executable. This can only be booted with a version of loader(8) newer than January 31, 2015, so make sure to update both world = and kernel before rebooting. . . . 20150131: The powerpc64 kernel has been changed to a position-independent executable. This can only be booted with a new version of = loader(8), so make sure to update both world and kernel before rebooting. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue May 9 03:15:15 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 B6005D649DB for ; Tue, 9 May 2017 03:15:15 +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 780F3EF3 for ; Tue, 9 May 2017 03:15:15 +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 v493FFcl050209 for ; Tue, 9 May 2017 03:15:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Tue, 09 May 2017 03:15:15 +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: Tue, 09 May 2017 03:15:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue May 9 17:26: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 CD78CD65BDC for ; Tue, 9 May 2017 17:26: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 BC54BD04 for ; Tue, 9 May 2017 17:26: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 v49HQlPk066127 for ; Tue, 9 May 2017 17:26:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Tue, 09 May 2017 17:26:47 +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: jhb@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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, 09 May 2017 17:26:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org Status|New |Open --- Comment #1 from John Baldwin --- I will work on fixing libkvm. Mark, can you verify that if you just replace 'ET_EXEC' with 'ET_DYN' as a hack that 'ps -M' works? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue May 9 18:16:56 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 B8DF2D65B34 for ; Tue, 9 May 2017 18:16:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-197.reflexion.net [208.70.211.197]) (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 6CC8F1AD1 for ; Tue, 9 May 2017 18:16:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20691 invoked from network); 9 May 2017 18:11:26 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 May 2017 18:11:26 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 09 May 2017 14:10:14 -0400 (EDT) Received: (qmail 22038 invoked from network); 9 May 2017 18:10:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 May 2017 18:10:14 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A5E57EC8B8D; Tue, 9 May 2017 11:10:13 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: A head -r317820 incremental buildworld race: kvm_geterr_test failures for -j16 but works without -j Message-Id: Date: Tue, 9 May 2017 11:10:12 -0700 Cc: Bryan Drewery To: FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) 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, 09 May 2017 18:16:56 -0000 I've had reason to be experimenting with libkvm recently and have repeatedly run into the following when doing buildworld with -j16. (I tend to run full buildworlds even for well-localized changes.) The context is having run buildworld to completion before so the update is incremental. --- kvm_geterr_test --- kvm_geterr_test.o: In function = `atfu_kvm_geterr_negative_test_NULL_body': /usr/src/lib/libkvm/tests/kvm_geterr_test.c:56: undefined reference to = `errbuf_has_error' kvm_geterr_test.o: In function = `atfu_kvm_geterr_positive_test_no_error_body': . . . --- kvm_geterr_test --- /usr/src/lib/libkvm/tests/kvm_geterr_test.c:108: undefined reference to = `errbuf_clear' /usr/src/lib/libkvm/tests/kvm_geterr_test.c:109: undefined reference to = `errbuf' /usr/src/lib/libkvm/tests/kvm_geterr_test.c:109: undefined reference to = `errbuf' /usr/src/lib/libkvm/tests/kvm_geterr_test.c:110: undefined reference to = `errbuf_has_error' kvm_geterr_test.o: In function = `atfu_kvm_geterr_positive_test_error_body': /usr/src/lib/libkvm/tests/kvm_geterr_test.c:73: undefined reference to = `errbuf_clear' /usr/src/lib/libkvm/tests/kvm_geterr_test.c:74: undefined reference to = `errbuf' /usr/src/lib/libkvm/tests/kvm_geterr_test.c:74: undefined reference to = `errbuf' /usr/src/lib/libkvm/tests/kvm_geterr_test.c:75: undefined reference to = `errbuf_has_error' /usr/src/lib/libkvm/tests/kvm_geterr_test.c:80: undefined reference to = `errbuf_has_error' By contrast if I omit -j completely the incremental buildworld runs to completion just fine. (rm -rf of the past buildworld and so building from scratch also works.) The context for my activity happens to use: # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_gcc421_bootstrap_c= lang-amd64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_gcc421_bootstrap_cla= ng-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-gcc421-bootstrap-clang.= amd64-host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang_gcc421" \ make $* # more = /root/src.configs/src.conf.powerpc-gcc421-bootstrap-clang.amd64-host 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 # WITHOUT_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG_FULL=3D WITHOUT_CLANG_EXTRAS=3D WITHOUT_LLD=3D WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITH_GCC_IS_CC=3D WITH_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue May 9 18:34: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 9AD2ED65A7C for ; Tue, 9 May 2017 18:34:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89B191EA for ; Tue, 9 May 2017 18:34:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v49IYaD7056961 for ; Tue, 9 May 2017 18:34:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Tue, 09 May 2017 18:34:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: Open 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: Tue, 09 May 2017 18:34:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #2 from Mark Millard --- (In reply to John Baldwin from comment #1) The ps -M result for using: # svnlite diff /usr/src/lib Index: /usr/src/lib/libkvm/kvm_private.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/lib/libkvm/kvm_private.c (revision 317820) +++ /usr/src/lib/libkvm/kvm_private.c (working copy) @@ -128,7 +128,9 @@ { return (kd->nlehdr.e_ident[EI_CLASS] =3D=3D class && - kd->nlehdr.e_type =3D=3D ET_EXEC && + ( kd->nlehdr.e_type =3D=3D ET_EXEC || + kd->nlehdr.e_type =3D=3D ET_DYN + ) && kd->nlehdr.e_machine =3D=3D machine); } on powerpc (head -r317820 variant) is: # ps -M /var/crash/vmcore.7 PID TT STAT TIME COMMAND I.e., the vmcore.* file is not rejected but no actual list of processes is generated. This is true of the other 6 vmcore.* 's that I have around as well. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue May 9 18:46:29 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 BEC20D65E34; Tue, 9 May 2017 18:46:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FD93A88; Tue, 9 May 2017 18:46:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 8DF894918; Tue, 9 May 2017 18:46:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7498371D8; Tue, 9 May 2017 18:46:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Rqwu15DQxtIi; Tue, 9 May 2017 18:46:22 +0000 (UTC) Subject: Re: A head -r317820 incremental buildworld race: kvm_geterr_test failures for -j16 but works without -j DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 25C7171D2 To: Mark Millard , FreeBSD Toolchain , FreeBSD Current References: From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <86edb67b-fc3b-9cce-1140-100e42f91055@FreeBSD.org> Date: Tue, 9 May 2017 11:46:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GNblHRPl3Pnb4tw3FeIm7GFicmH7EESWc" 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, 09 May 2017 18:46:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GNblHRPl3Pnb4tw3FeIm7GFicmH7EESWc Content-Type: multipart/mixed; boundary="3RpEIpwxUskcbN3gkc1oAD2pk7C4rLVlN"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , FreeBSD Toolchain , FreeBSD Current Message-ID: <86edb67b-fc3b-9cce-1140-100e42f91055@FreeBSD.org> Subject: Re: A head -r317820 incremental buildworld race: kvm_geterr_test failures for -j16 but works without -j References: In-Reply-To: --3RpEIpwxUskcbN3gkc1oAD2pk7C4rLVlN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/9/2017 11:10 AM, Mark Millard wrote: > I've had reason to be experimenting with libkvm recently > and have repeatedly run into the following when doing > buildworld with -j16. (I tend to run full buildworlds even > for well-localized changes.) The context is having run > buildworld to completion before so the update is > incremental. >=20 > --- kvm_geterr_test --- > kvm_geterr_test.o: In function `atfu_kvm_geterr_negative_test_NULL_body= ': > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:56: undefined reference to = `errbuf_has_error' > kvm_geterr_test.o: In function `atfu_kvm_geterr_positive_test_no_error_= body': > . . . > --- kvm_geterr_test --- > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:108: undefined reference to= `errbuf_clear' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:109: undefined reference to= `errbuf' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:109: undefined reference to= `errbuf' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:110: undefined reference to= `errbuf_has_error' > kvm_geterr_test.o: In function `atfu_kvm_geterr_positive_test_error_bod= y': > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:73: undefined reference to = `errbuf_clear' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:74: undefined reference to = `errbuf' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:74: undefined reference to = `errbuf' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:75: undefined reference to = `errbuf_has_error' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:80: undefined reference to = `errbuf_has_error' >=20 > By contrast if I omit -j completely the incremental > buildworld runs to completion just fine. (rm -rf of the > past buildworld and so building from scratch also works.) >=20 > The context for my activity happens to use: >=20 > # more ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_gcc421_b= ootstrap_clang-amd64-host.sh=20 > kldload -n filemon && \ > script ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_gcc421_boo= tstrap_clang-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" S= RC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-gcc421-bootstrap-clang.= amd64-host" \ > WITH_META_MODE=3Dyes \ Thanks for the report. Fixed in r318092. --=20 Regards, Bryan Drewery --3RpEIpwxUskcbN3gkc1oAD2pk7C4rLVlN-- --GNblHRPl3Pnb4tw3FeIm7GFicmH7EESWc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJZEg5vAAoJEDXXcbtuRpfP+ogIALe5uUlQZlX0o2n+2J4g73CO lxz2QzHMgPOj15S3CKgeOToX6j2/metwRZgODe66vmADwJ0f/xVgVwA/LOVzhJuy fbyV1mwwSRBiL3y3gEOKY6qqhNvA+cSVkIh1P7EIavdd5MWUE25ImXAiab/wQ1ge f8PEr4v9/JQKOdsGO6+qbyqNUrhyv/x9a9i8lc6xVfOhurNrDmgJJ9GbIBicosB/ 5NSh0sxeySqWA70APS/JoylT1GMBahYVo5ygnlo5Yr/fAmUKmB0gRlQmg5A1euBQ QgblUFO4FmseqZaiYive/YGASNh007zhMX05oZvOGX/7DO4Oec+DblgMlNnr1aU= =jAd2 -----END PGP SIGNATURE----- --GNblHRPl3Pnb4tw3FeIm7GFicmH7EESWc-- From owner-freebsd-toolchain@freebsd.org Tue May 9 22:23:22 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 8F777D65468 for ; Tue, 9 May 2017 22:23:22 +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 784AFB6E for ; Tue, 9 May 2017 22:23:22 +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 v49MNMBL098593 for ; Tue, 9 May 2017 22:23:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Tue, 09 May 2017 22:23:22 +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: Open 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: Tue, 09 May 2017 22:23:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #3 from Mark Millard --- (In reply to Mark Millard from comment #2) An FYI based on my ET_DYN test hack in libkvm: I've gotten some more panics with the libkvm change in place. This makes the new core.txt.* more interesting. Initially here I just emphasize where /usr/local/bin/gdb and /usr/libexec/gdb use in crashinfo got different results, picking an example vmcore file. 3c3 < Tue May 9 14:21:24 PDT 2017 --- > Tue May 9 14:58:07 PDT 2017 5c5 < FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc --- > FBSDG4S=20=20=20 9,24c9,15 < GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] . . . < This GDB was configured as "powerpc-portbld-freebsd12.0". . . . < Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. < done. --- > GNU gdb 6.1.1 [FreeBSD] . . . > This GDB was configured as "powerpc-marcel-freebsd"...kgdb: kvm_read:=20 25a17 >=20 38,39c30,31 < No thread selected. < (kgdb) No thread selected. --- > 0x00000000 in ?? () > (kgdb) #0 0x00000000 in ?? () 113,115c105,107 < cpu0:decrementer 140155 1757 < irq0: iichb0 104190 1306 < irq8: bge0 4043 51 --- > cpu0:decrementer 140155 117 > irq0: iichb0 104190 87 > irq8: bge0 4043 3 117c109 < irq70: ohci0 ohci1+ 22390 281 --- > irq70: ohci0 ohci1+ 22390 19 122c114 < irq27: iichb1 85 1 --- > irq27: iichb1 85 0 124,125c116,117 < irq10: atapci0 5778 72 < irq38: ata0 8593 108 --- > irq10: atapci0 5778 5 > irq38: ata0 8593 7 127,132c119,124 < irq53: smudoorbell0 30226 379 < irq124: IPI 237384 2976 < cpu3:decrementer 32632 409 < cpu1:decrementer 33061 415 < cpu2:decrementer 34929 438 < Total 653474 8193 --- > irq53: smudoorbell0 30226 25 > irq124: IPI 237384 197 > cpu3:decrementer 32632 27 > cpu1:decrementer 33061 27 > cpu2:decrementer 34929 29 > Total 653474 543 143c135 < Device 512-blocks Used Avail Capacity --- > Device 1K-blocks Used Avail Capacity 578,586c570,598 < 7f032b8 tcp4 0 0 *.111 *.* LISTEN < 7f03570 tcp6 0 0 *.111 *.* LISTEN < 7d56348 udp6 0 0 *.* *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 < 5ea8c08 udp4 0 0 *.901 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 < 5ea8d20 udp4 0 0 *.111 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 < 5ea8e38 udp6 0 0 *.903 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 < 5ea9000 udp6 0 0 *.111 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 < 5ea9118 udp4 0 0 *.514 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 < 5ea9230 udp6 0 0 *.514 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 --- > 8f93000 tcp4 0 0 192.168.1.7.22 192.168.1.106.4955 ESTABL= ISHED > a8732b8 tcp4 0 0 127.0.0.1.25 *.* LISTEN > 8fac570 tcp4 0 0 *.22 *.* LISTEN > 8fac828 tcp6 0 0 *.22 *.* LISTEN > 8fb9570 tcp6 0 0 *.2049 *.* LISTEN > 8fb9828 tcp4 0 0 *.2049 *.* LISTEN > 8facae0 tcp4 0 0 *.762 *.* LISTEN > 8fad000 tcp6 0 0 *.762 *.* LISTEN > 8f932b8 tcp4 0 0 *.111 *.* LISTEN > 8f93570 tcp6 0 0 *.111 *.* LISTEN > 8cbc8c0 udp4 0 0 127.0.0.1.123 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 8cbc9d8 udp6 0 0 fe80::1%lo0.123 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 8cbcaf0 udp6 0 0 ::1.123 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 8cbcc08 udp4 0 0 192.168.1.7.123 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 8cbcd20 udp6 0 0 2601:1c0:4301:25.1 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 8cbce38 udp6 0 0 fe80::214:51ff:f.1 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 8cbd000 udp4 0 0 *.123 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 8cbd118 udp6 0 0 *.123 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 62ad000 udp6 0 0 *.2049 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 62ad118 udp4 0 0 *.2049 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 8cbd230 udp4 0 0 *.762 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 8cbd348 udp6 0 0 *.762 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 62ad230 udp6 0 0 *.* *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 627a9d8 udp4 0 0 *.610 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 627aaf0 udp4 0 0 *.111 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 627ac08 udp6 0 0 *.1013 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 627ad20 udp6 0 0 *.111 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 627ae38 udp4 0 0 *.514 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > 627b000 udp6 0 0 *.514 *.*=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 595a608,614 > tcp4 0/0/10 localhost.smtp=20=20=20=20=20=20= =20=20=20 > tcp4 0/0/128 *.ssh=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > tcp6 0/0/128 *.ssh=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > tcp6 0/0/128 *.nfsd=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > tcp4 0/0/128 *.nfsd=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > tcp4 0/0/128 *.quotad=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 > tcp6 0/0/128 *.quotad=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 . . . (I do not show the < kernel configuration text here) . . . --- > Assertion failed: (i =3D=3D size - 1 && ("\\0 found in the middle of a fi= le")), function kernconfdump, file /usr/src/usr.sbin/config/main.c, line 73= 4. > Abort trap (core dumped) Some text that is not different based on which gdb but has odd content is: ------------------------------------------------------------------------ ps -axlww UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND ------------------------------------------------------------------------ vmstat -s 25198744 cpu context switches 1099617232 device interrupts 1099617232 software interrupts 1099617232 traps 1099617232 system calls 1099617232 kernel threads created 1099617232 fork() calls 1099617232 vfork() calls 1099617232 rfork() calls 1099617232 swap pager pageins 1099617232 swap pager pages paged in 1099617232 swap pager pageouts 1099617232 swap pager pages paged out 1099617232 vnode pager pageins 1099617232 vnode pager pages paged in 1099617232 vnode pager pageouts 1099617232 vnode pager pages paged out 1099617232 page daemon wakeups 1099617232 pages examined by the page daemon 1099617232 clean page reclamation shortfalls 1099617232 pages reactivated by the page daemon 1099617232 copy-on-write faults 1099617232 copy-on-write optimized faults 1099617232 zero fill pages zeroed 1099617232 zero fill pages prezeroed 1099617232 intransit blocking page faults 1099617232 total VM faults taken 1099617232 page faults requiring I/O 1099617232 pages affected by kernel thread creation 1099617232 pages affected by fork() 1099617232 pages affected by vfork() 1099617232 pages affected by rfork() 1099617232 pages freed 1099617232 pages freed by daemon 1099617232 pages freed by exiting processes 0 pages active 0 pages inactive 0 pages in the laundry queue 0 pages wired down 0 pages free 0 bytes per page 0 total name lookups cache hits (0% pos + 0% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% The following had titles but no content: vmstat -m vmstat -z pstat -s netstat -m fstat The following got an error: iostat iostat: readkmem: error reading value (kvm_read):=20 The following reported all zeros: nfsstat netstat -s --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed May 10 00:59: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 22E6CD65260 for ; Wed, 10 May 2017 00:59:02 +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 F2E061F53 for ; Wed, 10 May 2017 00:59:01 +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 v4A0x1lV013466 for ; Wed, 10 May 2017 00:59:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Wed, 10 May 2017 00:59:02 +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: Open 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, 10 May 2017 00:59:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #4 from Mark Millard --- A not as libkvm tied note about which gdb works better for 32-bit powerpc in at least some contexts: I took an a.out (from clang++=20 targeting powerpc) and tried /usr/local/bin/gdb and /usr/libexec/gdb on a core it generated: # gdb a.out /var/crash/a.out.29973.core=20 GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] . . . Core was generated by `./a.out'. Program terminated with signal SIGSEGV, Segmentation fault. Segmentation fault (core dumped) (gdb itself Segmentation faulted.) # /usr/libexec/gdb a.out /var/crash/a.out.29973.core GNU gdb 6.1.1 [FreeBSD] . . . Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc++.so.1...Reading symbols from /usr/lib/debug//usr/lib/libc++.so.1.debug...done. . . . Loaded symbols for /libexec/ld-elf.so.1 #0 0x41b355d0 in _Unwind_SetGR (context=3D, index=3D<= value optimized out>, val=3D1105281072) at unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x41b355d0 in _Unwind_SetGR (context=3D, index=3D<= value optimized out>, val=3D1105281072) at unwind-dw2-fde.h:162 #1 0x4192e370 in __gxx_personality_v0 (version=3D, actions=3D, exceptionObject=3D0x41e14030, context=3D0x= ffffd5c0) at /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x41b36234 in _Unwind_RaiseException_Phase2 (exc=3D, context=3D) at unwind.inc:66 #3 0x41b35e10 in _Unwind_RaiseException (exc=3D0xffffd5c0) at unwind.inc:1= 35 #4 0x4192d870 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x01800954 in main () at exception_test.cpp:5 Current language: auto; currently minimal The same thing happens for running the a.out inside gdb: /usr/local/bin/gdb gets a Segmentation fault of its own and /usr/libexec/gdb works, including allowing the bt. Historically I've primarily used the system gdb to do my analysis of clang's code generation problems for targeting powerpc. Including when I looked at gcc 4.2.1 generated code for comparison. The above sort of thing is an example of why. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed May 10 15:53:14 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 12047D672A1 for ; Wed, 10 May 2017 15:53:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00FBB16F2 for ; Wed, 10 May 2017 15:53:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4AFrDIb005882 for ; Wed, 10 May 2017 15:53:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Wed, 10 May 2017 15:53:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Open 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, 10 May 2017 15:53:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #5 from John Baldwin --- I would start with trying to debug why 'ps -M' doesn't work by stepping thr= ough 'ps'. In terms of gdb7 vs gdb6, I definitely used gdb7 on userland binaries with threads, fork following, etc. last year under qemu for ppc64. The gdb port= has a DEBUG option that will build gdb with debug symbols. Can you build your = gdb port with that (if not already enabled) and get a stack trace from the gdb.core? You can use /usr/libexec/gdb to examine the core of gdb7 for now= .=20 Alternatively, you can grab the a.out and core file from a ppc system and d= ebug it using the gdb binary from ports on an amd64 host (the ports gdb includes cross-debugging of user cores for all supported architectures). It may be = that the amd64 gdb7 also cores, but if so you will be able to debug the amd64 gd= b7 using a native gdb7 on amd64. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed May 10 16:56:10 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 EEB59D66C61 for ; Wed, 10 May 2017 16:56:10 +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 DDA40B11 for ; Wed, 10 May 2017 16:56:10 +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 v4AGuAfF066790 for ; Wed, 10 May 2017 16:56:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Wed, 10 May 2017 16:56:11 +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: Open 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, 10 May 2017 16:56:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #6 from Mark Millard --- (In reply to John Baldwin from comment #5) I've used both gdb's as well but I've had more occasions when system's gdb worked and ports did not than the other way around (when there is a distinction). (Historically, not just now.) Okay I'll poke at ps -M and the /usr/local/bin/gdb crash. Be warned: I'm also currently evidence-gathering for two folks working on the clang powerpc and/or powerpc64 targeting support so my FreeBSD time is split. This also leads to context switching between a world built with gcc 4.2.1 and one built with clang. If I'm interrupted I can forget to switch and, for example, end up seeing the clang issues without initially noticing why (clang built system libraries, for example). I'll rerun the /usr/local/bin/gdb test explicitly on a gcc 4.2.1 built world just in case that happened yesterday. (clang generates powerpc and powerpc64 "code" that has handling of thrown-C++-exceptions completely broken, leading to segmentation faults while trying to reach landing-pad code. "Code": incomplete dwarf information.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed May 10 21:50: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 C2082D67CE0 for ; Wed, 10 May 2017 21:50: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 B085F115E for ; Wed, 10 May 2017 21:50: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 v4ALoj5d058442 for ; Wed, 10 May 2017 21:50:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Wed, 10 May 2017 21:50:45 +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: Open 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, 10 May 2017 21:50:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #7 from Mark Millard --- (In reply to John Baldwin from comment #5) This note is for the /usr/local/bin/gdb crash. As for building ports with debug information, I use as a default context: # svnlite diff /usr/ports/Mk/ Index: /usr/ports/Mk/bsd.port.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/Mk/bsd.port.mk (revision 440115) +++ /usr/ports/Mk/bsd.port.mk (working copy) @@ -1639,7 +1639,11 @@ STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif and: # more /etc/make.conf=20 WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D6 WRKDIRPREFIX=3D/usr/obj/portswork # # From a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .elif ${.CURDIR:M*/www/webkit-qt5*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif WITH_DEBUG_FILES=3D MALLOC_PRODUCTION=3D (WITH_DEBUG=3D makes level/llvm40 and www/webkit-qt5 massively large, which I avoid. It has been years since I've built or used www/webkit-qt5, however.) An example core file bt for /usr/local/bin/gdb getting its own segmentation fault is as follows. Note #11 and its memaddr=3D8 . (#0-#10 are the attempted handling of the bad (and incorrect?) address, but the attempt got its own failure.) #0 0x430935d0 in _Unwind_SetGR (context=3D, index=3D<= value optimized out>, val=3D1130509136) at unwind-dw2-fde.h:162 162 { Cannot find new threads: generic error (gdb) bt #0 0x430935d0 in _Unwind_SetGR (context=3D, index=3D<= value optimized out>, val=3D1130509136) at unwind-dw2-fde.h:162 #1 0x432c53b8 in __gxx_personality_v0 (version=3D, actions=3D6, exception_class=3D, ue_header=3D0x4362335= 0, context=3D0xffffd0a0) at /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_personal= ity.cc:681 #2 0x43094234 in _Unwind_RaiseException_Phase2 (exc=3D, context=3D) at unwind.inc:66 #3 0x43093e10 in _Unwind_RaiseException (exc=3D0xffffd0a0) at unwind.inc:1= 35 #4 0x432c4778 in __cxa_throw (obj=3D, tinfo=3D, dest=3D) at /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc= :71 #5 0x01c9f398 in throw_exception_cxx (exception=3D{reason =3D RETURN_ERROR= , error =3D MEMORY_ERROR, message =3D 0x43748400 "Cannot access memory at address 0= x8"}) at ./common/common-exceptions.c:303 #6 0x01c9f42c in throw_exception (exception=3DCannot access memory at addr= ess 0x0 ) at ./common/common-exceptions.c:317 #7 0x01c9f4f8 in throw_it (reason=3D1130509136, error=3DMEMORY_ERROR, fmt= =3D, ap=3D) at ./common/common-exceptions.c= :373 #8 0x01c9f5ec in throw_verror (error=3D, fmt=3D, ap=3D) at ./common/common-exceptions.c= :379 #9 0x01c9f65c in throw_error (error=3D, fmt=3D) at ./common/common-exceptions.c:394 #10 0x01bedcf8 in memory_error (err=3D, memaddr=3D) at corefile.c:237 #11 0x01bedfbc in read_memory_object (object=3DTARGET_OBJECT_MEMORY, memadd= r=3D8, myaddr=3D0xffffd940 "???`C\027\024????????\033???p", len=3D) at corefile.c:261 #12 0x01bee1b0 in read_memory_typed_address (addr=3D, type=3D0x438e0018) at corefile.c:400 #13 0x019b42b8 in solib_svr4_r_map (info=3D0x44002084) at solib-svr4.c:913 #14 0x019b4648 in svr4_current_sos_direct (info=3D0x436232c0) at solib-svr4.c:1494 #15 0x019b4e40 in svr4_current_sos () at solib-svr4.c:1528 #16 0x01c71264 in update_solib_list (from_tty=3D26952375, target=3D) at solib.c:767 #17 0x01c71b4c in solib_add (pattern=3D0x0, from_tty=3D0, target=3D0x2d4310= 0, readsyms=3D1) at solib.c:994 #18 0x01b33eb4 in post_create_inferior (target=3D0x2d43100, from_tty=3D1) at infcmd.c:461 #19 0x01ade424 in core_open (arg=3D, from_tty=3D1) at corelow.c:407 #20 0x01bee65c in core_file_command (filename=3D0xffffde21 "/var/crash/a.out.29973.core", from_tty=3D1) at corefile.c:77 #21 0x01b583b8 in catch_command_errors (command=3D0x1bee610 , arg=3D, from_tty=3D1)= at main.c:375 #22 0x01b593f0 in captured_main (data=3D) at main.c:10= 81 #23 0x01b596ac in gdb_main (args=3D0xffffdcb8) at main.c:1159 #24 0x01890d54 in main (argc=3D, argv=3D0xffffdcfc) at gdb.c:38 Current language: auto; currently minimal The original program /usr/local/bin/gdb was looking at was a simple C++ exception handling test compiled by system-clang++ on a world built by system-clang. (Tied to my getting evidence of things for the 2 folks working on things for targeting powerpc via clang.) That original a.out gets its own segmentation fault due to what clang generated. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed May 10 23:25:12 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 D57E0D67AC7 for ; Wed, 10 May 2017 23:25:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C46A8131B for ; Wed, 10 May 2017 23:25:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4ANPCbs022962 for ; Wed, 10 May 2017 23:25:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Wed, 10 May 2017 23:25:12 +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: jhb@FreeBSD.org X-Bugzilla-Status: Open 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, 10 May 2017 23:25:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #8 from John Baldwin --- Can you pop up to frame 13 (solib_svr4_r_map) and 'p *info' and 'p *lmo'? = The lack of working exceptions from clang (which appears to be the source of the coredump in gdb itself) might be problematic though. gdb might very well depend on working exceptions to work properly. The current gdb7.12.1 can be compiled with gcc4.2.1 still which might work better than compiling with cl= ang. The next gdb release (8.0) requires C++11 which will need an external gcc = or fully functional clang. I've been using mips-gcc to build gdb 'master' for FreeBSD/mips just fine against a MIPS world built via mips-xtoolchain-gcc (= both 32-bit and 64-bit). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu May 11 00:13:15 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 AF0DCD67840 for ; Thu, 11 May 2017 00:13:15 +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 888DFAC7 for ; Thu, 11 May 2017 00:13:15 +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 v4B0DFlX066914 for ; Thu, 11 May 2017 00:13:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Thu, 11 May 2017 00:13:15 +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: Open 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, 11 May 2017 00:13:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #9 from Mark Millard --- (In reply to John Baldwin from comment #5) As for ps -M /var/crash/vmcore.7 listing no processes: main uses kvm_getprocs, which in turn eventually does: if (KREAD(kd, nl[0].n_value, &nprocs)) { _kvm_err(kd, kd->program, "can't read nproc= s"); return (0); } but that ends up with: (gdb) print nprocs $2 =3D 12873340 (I checked the code and "info reg" and the value matched.) So things are already well messed up here. That in turn ends up used in: size =3D nprocs * sizeof(struct kinfo_proc); kd->procbase =3D (struct kinfo_proc *)_kvm_malloc(k= d, size); if (kd->procbase =3D=3D NULL) return (0); which succeeds but later there is: nprocs =3D kvm_deadprocs(kd, op, arg, nl[1].n_value, nl[2].n_value, nprocs); if (nprocs <=3D 0) { _kvm_freeprocs(kd); nprocs =3D 0; } which in kvm_deadprocs gets to: if (KREAD(kd, a_allproc, &p)) { _kvm_err(kd, kd->program, "cannot read allproc"); return (-1); } acnt =3D kvm_proclist(kd, what, arg, p, bp, maxcnt); if (acnt < 0) return (acnt); where: static int kvm_proclist(kvm_t *kd, int what, int arg, struct proc *p, struct kinfo_proc *bp, int maxcnt) { int cnt =3D 0; . . . is used via: kvm_proclist (kd=3D0x41e14000, what=3D5, arg=3D0, p=3D0x0, bp=3D0x42000000, maxcnt=3D12873340) and the internal kvm_proclist loop no-ops because of p: for (; cnt < maxcnt && p !=3D NULL; p =3D LIST_NEXT(&proc, = p_list)) { So no process is listed. After the loop is: return (cnt); } And that means: nprocs =3D kvm_deadprocs(kd, op, arg, nl[1].n_value, nl[2].n_value, nprocs); if (nprocs <=3D 0) { _kvm_freeprocs(kd); nprocs =3D 0; } ends up with nprocs=3D=3D0 and kd is freed, hopefully including kd->procbase being freed (I did not look). But overall: at least one KREAD gets back a junk figure. And with that I think I will stop for this note. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu May 11 01:34:39 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 56630D670C1 for ; Thu, 11 May 2017 01:34:39 +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 3B8CA1994 for ; Thu, 11 May 2017 01:34:39 +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 v4B1YcT9060771 for ; Thu, 11 May 2017 01:34:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Thu, 11 May 2017 01:34:39 +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: Open 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, 11 May 2017 01:34:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #10 from Mark Millard --- (In reply to John Baldwin from comment #8) The bt that I included shows libstdc++ in use inside /usr/local/bin/gdb, not libc++ . This is because /usr/local/bin/gdb was built under a gcc 4.2.1 world via the gcc 4.2.1 compiler (no clang present at the time). # ldd /usr/local/bin/gdb /usr/local/bin/gdb: libreadline.so.6 =3D> /usr/local/lib/libreadline.so.6 (0x42ba4000) libncurses.so.8 =3D> /lib/libncurses.so.8 (0x42bfc000) libkvm.so.7 =3D> /lib/libkvm.so.7 (0x42c55000) libutil.so.9 =3D> /lib/libutil.so.9 (0x42c77000) libthr.so.3 =3D> /lib/libthr.so.3 (0x42c9b000) libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x42cd6000) libm.so.5 =3D> /lib/libm.so.5 (0x42cf1000) libpython2.7.so.1 =3D> /usr/local/lib/libpython2.7.so.1 (0x42d28000) libexpat.so.1 =3D> /usr/local/lib/libexpat.so.1 (0x42f12000) liblzma.so.5 =3D> /usr/lib/liblzma.so.5 (0x42f4b000) libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x42f83000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x43095000) libc.so.7 =3D> /lib/libc.so.7 (0x430b5000) libelf.so.2 =3D> /lib/libelf.so.2 (0x4325a000) (Avoiding delete-old-libs keeps libraries around that otherwise would not exist when I context switch. gcc-4.2.1-based and clang-based are based on the same /usr/src built two ways.) /usr/local/bin/gdb does use C++ exceptions internally, at least for some things. It is the original a.out that has clang-based bindings (libcxxrt.so.1 and libc++.so.1): # ldd ~/c_tests/a.out /root/c_tests/a.out: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x4183b000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x4191e000) libm.so.5 =3D> /lib/libm.so.5 (0x41949000) libc.so.7 =3D> /lib/libc.so.7 (0x41980000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x41b33000) FYI: # ldd /usr/libexec/gdb=20 /usr/libexec/gdb: libm.so.5 =3D> /lib/libm.so.5 (0x41afa000) libncursesw.so.8 =3D> /lib/libncursesw.so.8 (0x41b31000) libgnuregex.so.5 =3D> /usr/lib/libgnuregex.so.5 (0x41b96000) libc.so.7 =3D> /lib/libc.so.7 (0x41bba000) (So fewer dependencies to have working well for it to be "working". No C++ library use.) As for #13, *info, and *lmo: #13 0x019b42b8 in solib_svr4_r_map (info=3D0x44002084) at solib-svr4.c:913 #14 0x019b4648 in svr4_current_sos_direct (info=3D0x436232c0) at solib-svr4.c:1494 #14 has the right address for info. #13 is reporting the R30 value as the info address for some reason (R30 is frequently used for PIC support in powerpc land). svr4_current_sos_direct passes its info value to solib_svr4_r_map unchanged. (gdb) up 14 #14 0x019b4648 in svr4_current_sos_direct (info=3D0x436232c0) at solib-svr4.c:1494 1494 lm =3D solib_svr4_r_map (info); Current language: auto; currently c++ (gdb) print *info $1 =3D {debug_base =3D 4, debug_loader_offset_p =3D 0, debug_loader_offset = =3D 0, debug_loader_name =3D 0x0, main_lm_addr =3D 0, interp_text_sect_low =3D 0, interp_text_sect_high =3D 0, interp_plt_sect_low =3D 0,=20 interp_plt_sect_high =3D 0, using_xfer =3D 0, probes_table =3D 0x0, solib= _list =3D 0x0} (gdb) down #13 0x019b42b8 in solib_svr4_r_map (info=3D0x44002084) at solib-svr4.c:913 913 ptr_type); (gdb) print *lmo $2 =3D {r_version_offset =3D 0, r_version_size =3D 4, r_map_offset =3D 4, r= _brk_offset =3D 8, r_ldsomap_offset =3D 20, link_map_size =3D 20, l_addr_offset =3D 0, = l_ld_offset =3D 8, l_next_offset =3D 12,=20 l_prev_offset =3D 16, l_name_offset =3D 4} This is via /usr/libexec/gdb on the same system build that a.out was produced and tested on (clang based). Other notes: /usr/local/bin/gdb segmentation faults looking at its own core file, much like it does looking at the a.out core file. I will note that in comment #3's list of differences it was /usr/libexec/gdb that got things like the rates for interrupts correct. (Both gdb's listed the same counts --but got very different rates. /usr/local/bin/gdb showed to rates that were too large by a lot.) Similar points go for other parts of the diff: /usr/libexec/gdb got more correct. This was a gcc 4.2.1 based environment, not clang-based. --=20 You are receiving this mail because: You are the assignee for the bug.=