Date: Wed, 10 May 2017 15:53:13 +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-gAZJB8Vf9l@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 #5 from John Baldwin <jhb@FreeBSD.org> --- 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219153-29464-gAZJB8Vf9l>