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]

[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 freebsd.org> wrote:

> On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote:
>> THING #0:
>> 
>> 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:
>> 
>> 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:
> 
> https://github.com/bsdjhb/gdb/compare/freebsd-7.11-kgdb...kgdb-ppc

Interesting.

>> 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	{
129	
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 dsl-only.net