[Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such

2017-05-08 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

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"

2017-05-08 Thread Mark Millard 
[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  wrote:

> [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  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>: stwur1,-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>:cmpwr3,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>:addir1,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.

I've submitted bugzilla 219153 for this libvm issue of
not handling

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"

2017-05-08 Thread 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  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>:   stwur1,-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>:  cmpwr3,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>:  addir1,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

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

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"

2017-05-08 Thread John Baldwin 
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

> THING #1:
> 
> Another oddity is for the combination:
> 
> ${MK_GDB} == no && ${MK_GDB_LIBEXEC} == yes

As I think you figured out, MK_GDB_LIBEXEC depends on MK_GDB=yes.
If WITHOUT_GDB=yes is set, then no "base" GDB is installed at all.
WITH_GDB_LIBEXEC is just to decide in the MK_GDB=yes case where
"base" GDB goes: /usr/bin vs /usr/libexec.

> 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.

-- 
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"