Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target"

Mark Millard markmi at
Mon May 8 20:25:06 UTC 2017

[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 <jhb at> wrote:

> On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote:
>> THING #0:
>> It appears that usr.sbin/crashinfo/ assumes
>> that /usr/local/bin/gdb will work better for all architectures,
>> including for kgdb types of activity:
>> find_gdb()
>> {
>>        local binary
>>        for binary in /usr/local/bin/gdb /usr/libexec/gdb /usr/bin/gdb; do
>>                if [ -x ${binary} ]; then
>>                        GDB=${binary}
>>                        return
>>                fi
>>        done
>> }
>> But it appears that on powerpc /usr/local/bin/gdb and
>> /usr/local/bin/kgdb do not support TARGET_ARCH=powerpc
>> at all for such activity.
> 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:


>> THING #1:
>> . . .
>> THING #2:
>> /usr/libexec/kgdb (when present) does not support the
>> powerpc architecture for head either . . .
>> On a head -r317820 powerpc I attempted:
>> # /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
> 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	{
130		return (kd->nlehdr.e_ident[EI_CLASS] == class &&
131		    kd->nlehdr.e_type == ET_EXEC &&
132		    kd->nlehdr.e_machine == machine);
133	}

gets false via: kd->nlehdr.e_type == ET_EXEC

(gdb) print kd->nlehdr.e_type
$4 = 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.

Mark Millard
markmi at

More information about the freebsd-ports mailing list