Date: Mon, 8 May 2017 14:36:54 -0700 From: Mark Millard <markmi@dsl-only.net> To: John Baldwin <jhb@freebsd.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, andreast@freebsd.org, FreeBSD Ports <freebsd-ports@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Lack of TARGET_ARCH=powerpc support in kgdb from devel/gdb (e.g., -r440115 of /usr/ports): "ABI doesn't support a vmcore target" Message-ID: <599466E6-DDFB-4C94-B16D-B0F5CA787431@dsl-only.net> In-Reply-To: <3A7CC677-0946-4BF3-8622-530BF274605F@dsl-only.net> References: <CC5B5B39-A4FE-4C30-B936-E368863F512F@dsl-only.net> <568491A5-0BDC-41CD-945C-E42B53EC2393@dsl-only.net> <2567165.qjEVz8HF8R@ralph.baldwin.cx> <3A7CC677-0946-4BF3-8622-530BF274605F@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[I've submitted bugzilla 219153 for this libvm issue of
not handling powerpc's/powerp64's ET_DYN vmcore.* 's and
such.]
On 2017-May-8, at 1:18 PM, Mark Millard <markmi@dsl-only.net> wrote:
> [Mostly: Why THING #2 fails: checks for ET_EXEC
> but the actual vmcore.* 's have ET_DYN instead.]
>=20
> On 2017-May-8, at 11:30 AM, John Baldwin <jhb at freebsd.org> wrote:
>=20
>> On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote:
>>> THING #0:
>>>=20
>>> 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:
>>>=20
>>> find_gdb()
>>> {
>>> local binary
>>>=20
>>> for binary in /usr/local/bin/gdb /usr/libexec/gdb =
/usr/bin/gdb; do
>>> if [ -x ${binary} ]; then
>>> GDB=3D${binary}
>>> return
>>> fi
>>> done
>>> }
>>>=20
>>> But it appears that on powerpc /usr/local/bin/gdb and
>>> /usr/local/bin/kgdb do not support TARGET_ARCH=3Dpowerpc
>>> at all for such activity.
>>=20
>> 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:
>>=20
>> https://github.com/bsdjhb/gdb/compare/freebsd-7.11-kgdb...kgdb-ppc
>=20
> Interesting.
>=20
>>> THING #1:
>>> . . .
>>=20
>>> THING #2:
>>>=20
>>> /usr/libexec/kgdb (when present) does not support the
>>> powerpc architecture for head either . . .
>>>=20
>>> On a head -r317820 powerpc I attempted:
>>>=20
>>> # /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
>>=20
>> 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.
>=20
> For THING #2:
>=20
> I had to use /usr/libexec/gdb as the debugger because =
/usr/local/bin/gdb
> segmentation faulted.
>=20
> (gdb) list
> 126 int
> 127 _kvm_probe_elf_kernel(kvm_t *kd, int class, int machine)
> 128 {
> 129=09
> 130 return (kd->nlehdr.e_ident[EI_CLASS] =3D=3D class &&
> 131 kd->nlehdr.e_type =3D=3D ET_EXEC &&
> 132 kd->nlehdr.e_machine =3D=3D machine);
> 133 }
>=20
> gets false via: kd->nlehdr.e_type =3D=3D ET_EXEC
>=20
> (gdb) print kd->nlehdr.e_type
> $4 =3D 3
>=20
> but the comparison is for:
>=20
> 0x41882fe0 <_kvm_probe_elf_kernel+32>: cmplwi cr1,r4,2
>=20
> (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
>=20
> powerpc and powerpc64 use position independent kernels
> these days as I remember, making kd->nlehdr.e_type be
> ET_DYN instead of ET_EXEC :
>=20
> /* e_type */
> #define ET_REL 1
> #define ET_EXEC 2
> #define ET_DYN 3
> #define ET_CORE 4
>=20
> I do not know if more needs to change than just
> the enabling test since the content is ET_DYN
> type of material.
>=20
> It looks like the conversion to position independent
> kernels for powerpc and powerpc64 did not cover all
> the related infrastructure, such as libkvm.
I've submitted bugzilla 219153 for this libvm issue of
not handling powerpc's/powerp64's ET_DYN vmcore.* 's and
such.
It applies to head , stable/11 , and release/11.0.1 :
20150307:
The 32-bit PowerPC kernel has been changed to a =
position-independent
executable. This can only be booted with a version of loader(8)
newer than January 31, 2015, so make sure to update both world =
and
kernel before rebooting.
. . .
20150131:
The powerpc64 kernel has been changed to a position-independent
executable. This can only be booted with a new version of =
loader(8),
so make sure to update both world and kernel before rebooting.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?599466E6-DDFB-4C94-B16D-B0F5CA787431>