From owner-freebsd-ports@freebsd.org Mon May 8 20:25:06 2017 Return-Path: Delivered-To: freebsd-ports@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 55F7CD62AF0 for ; Mon, 8 May 2017 20:25:06 +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 B84AB150 for ; Mon, 8 May 2017 20:25:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21098 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-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 20:25: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