From owner-freebsd-toolchain@freebsd.org Sun May 14 13:19: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 C398BD6CF23 for ; Sun, 14 May 2017 13:19: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 A9BF81166 for ; Sun, 14 May 2017 13:19: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 v4EDJMd5011220 for ; Sun, 14 May 2017 13:19: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: Sun, 14 May 2017 13:19: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: Sun, 14 May 2017 13:19:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #14 from Mark Millard --- (In reply to John Baldwin from comment #8) With the following hacks I've been able to get an output for the debug.minidump=3D0 based vmcore.2 (2 GiBYte RAM dumped) for powerpc (32-bit) FreeBSD via: # ps -aux -M /var/crash/vmcore.2 -N /usr/lib/debug/boot/kernel/kernel.debug= =20 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 0 0.0 0.0 0 0 - DLs 31Dec69 0:00.11 [kernel] root 1 0.0 0.0 5400 792 - DLs 31Dec69 0:00.06 [init] root 2 0.0 0.0 0 0 - DL 31Dec69 0:00.00 [crypto] root 3 0.0 0.0 0 0 - DL 31Dec69 0:00.00 [crypto returns] . . . markmi 1086 0.0 0.2 14192 4168 - D 31Dec69 0:00.00 [sshd] markmi 1087 0.0 0.1 7048 2812 - Ds 31Dec69 0:00.00 [sh] root 1088 0.0 0.1 7900 2660 - D 31Dec69 0:00.00 [su] root 1089 0.0 0.1 7048 2800 - D+ 31Dec69 0:00.00 [sh] (The STARTED column output is odd above.) Be warned that I've not done much FreeBSD coding and so am not familiar with the coding standards and/or guidelines and just did my own thing. # svnlite diff /usr/src/lib/libkvm/kvm_private.c 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); } Then in: static int _powerpc_kvatop(kvm_t *kd, kvaddr_t va, off_t *ofs) I did: # svnlite diff /usr/src/lib/libkvm/kvm_powerpc.c Index: /usr/src/lib/libkvm/kvm_powerpc.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_powerpc.c (revision 317820) +++ /usr/src/lib/libkvm/kvm_powerpc.c (working copy) @@ -209,6 +209,53 @@ if (be32toh(vm->ph->p_paddr) =3D=3D 0xffffffff) return ((int)powerpc_va2off(kd, va, ofs)); + // HACK in something for what I observe in + // a debug.minidump=3D0 vmcore.* for 32-bit powerpc + // + if ( be32toh(vm->ph->p_vaddr) =3D=3D 0xffffffff + && be32toh(vm->ph->p_paddr) =3D=3D 0 + && be16toh(vm->eh->e_phnum) =3D=3D 1 + ) { + // Presumes p_memsz is either unsigned + // 32-bit or is 64-bit, same for va . + + if (be32toh(vm->ph->p_memsz) <=3D va) + return 0; // Like powerpc_va2off + + // If ofs was (signed) 32-bit there + // would be a problem for sufficiently + // large postive memsz's and va's + // near the end --because of p_offset + // and dmphdrsz causing overflow/wrapping + // for some large va values. + // Presumes 64-bit ofs for such cases. + // Also presumes dmphdrsz+p_offset + // is non-negative so that small + // non-negative va values have no + // problems with ofs going negative. + + *ofs =3D vm->dmphdrsz + + be32toh(vm->ph->p_offset) + + va; + + // The normal return value overflows/wraps + // for p_memsz =3D=3D 0x80000000u when va =3D=3D 0 . + // Avoid this by depending on calling code's + // loop for sufficiently large cases. + // This code presumes p_memsz/2 <=3D MAX_INT . + // 32-bit powerpc FreeBSD does not allow + // using more than 2 GiBytes of RAM but + // does allow using 2 GiBytes on 64-bit + // hardware. + // + if ( (int)be32toh(vm->ph->p_memsz) < 0 + && va < be32toh(vm->ph->p_memsz)/2 + ) + return be32toh(vm->ph->p_memsz)/2; + + return be32toh(vm->ph->p_memsz) - va; + } + _kvm_err(kd, kd->program, "Raw corefile not supported"); return (0); } (Technically I combined this with my clang targeting powerpc 32-bit testing by building it as a clang based buildworld.) I do not claim the code is appropriate for FreeBSD use but it might get me closer to investigating why production-style kernel builds (gcc 4.2.1 based) panic on a pid 11 (idle process) thread every so often, even when world was also gcc 4.2.1 based. --=20 You are receiving this mail because: You are the assignee for the bug.=