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