Date: Sun, 14 May 2017 13:19:22 +0000 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 Message-ID: <bug-219153-29464-V78SfCWOO7@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219153-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-219153-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #14 from Mark Millard <markmi@dsl-only.net> --- (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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219153-29464-V78SfCWOO7>