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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

John Baldwin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|Open|Closed

--- Comment #20 from John Baldwin  ---
Marking this as fixed as libkvm now generally works with powerpc64.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #19 from Leandro Lupori  ---
(In reply to Mark Millard from comment #18)

> GNU gdb (GDB) 8.3.1 [GDB v8.3.1 for FreeBSD] got:
>
> inferior.c:287: internal-error: struct inferior *find_inferior_pid(int):
> Assertion `pid != 0' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) y

I was seeing this error before libkvm and gdb were fixed.
On CURRENT, with a recent world and gdb this error should not be seen.
To get all fixes, a base system later than February 7 and a gdb from ports
later than February 27 must be used.

> By contrast, GNU gdb 6.1.1 [FreeBSD] got:

The older gdb from base is known to have many issues, that are probably not
going to be fixed.


> Attempting a non-minidump hung up during
> the dump, much like for powerpc64.

I've worked only on minidumps for powerpc64.
Full dumps were not touched at all, so if they didn't work before, they
probably won't work now.


> I'm not so sure that the current G4
> behavior should be classified with this
> submittal. I'll leave it to you if you
> want this submittal closed in some way.
> Most of the information is probably too
> old to be of much use for going forwards
> as far as old PowerMacs go.

I don't have G4/G5 hardware to test this.
G4s are 32-bit, right? I wouldn't expect minidumps to work on them, as their
kernel and libkvm specific parts would need to be added/fixed.
But minidumps should work on G5, I think, although I wasn't able to test it.

So, maybe mark this as fixed and track minidumps not working on G5 as another
issue and minidump support on G4 as an enhancement?

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #18 from Mark Millard  ---
(In reply to Leandro Lupori from comment #17)

I tried a 2-socket PowerMac G4 (head -r358510)
and, for a minidump, after reboot . . .

GNU gdb (GDB) 8.3.1 [GDB v8.3.1 for FreeBSD] got:

inferior.c:287: internal-error: struct inferior *find_inferior_pid(int):
Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

(I've seen reports with such for other platforms
in the past.)


By contrast, GNU gdb 6.1.1 [FreeBSD] got:

kgdb: kvm_read: 
No symbol "zombproc" in current context.
0x in ?? ()
(kgdb) bt
#0  0x in ?? ()

(Not so useful.)


Attempting a non-minidump hung up during
the dump, much like for powerpc64. (I did
have to make the dump partition be somewhat
bigger than 2048 MiBytes to prevent being
told that it was too small.)

I used to be able to make such dumps under
32-bit powerpc FreeBSD. But it has been a
long time since I've tried such so I've
no clue when it stopped being able to
write such dumps. (Analyzing them had its
own issues.)


I'm not so sure that the current G4
behavior should be classified with this
submittal. I'll leave it to you if you
want this submittal closed in some way.
Most of the information is probably too
old to be of much use for going forwards
as far as old PowerMacs go.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #17 from Leandro Lupori  ---
I've tested dumping and inspecting the crashdump using r358813, on a POWER8 VM.
It worked fine.

These were the test commands and output:

# sysctl debug.kdb.panic=1
...
db> dump
Dumping 216 out of 8148 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Dump complete
db> panic
panic: from debugger
...
(reboot)
...
Mar 11 15:53:08 fbsd2 savecore[534]: reboot after panic: kdb_sysctl_panic
Writing crash summary to /var/crash/core.txt.1.
...

# kgdb /boot/kernel/kernel /var/crash/vmcore.last
...
Unread portion of the kernel message buffer: 
panic: kdb_sysctl_panic 
cpuid = 6   
time = 1583952756   
KDB: stack backtrace:   
0xe0005758b030: at kdb_backtrace+0x60   
0xe0005758b140: at vpanic+0x1e4 
0xe0005758b1f0: at panic+0x40 
0xe0005758b220: at kdb_sysctl_panic+0xa4
0xe0005758b2a0: at sysctl_root_handler_locked+0x114  
0xe0005758b310: at sysctl_root+0x290   
0xe0005758b400: at userland_sysctl+0x174  
0xe0005758b520: at sys___sysctl+0x8c
0xe0005758b610: at trap+0x940   
0xe0005758b750: at powerpc_interrupt+0x1b8 
0xe0005758b7e0: user SC trap by 0x8102b6110: srr1=0x8280f032
r1=0x3fffc300 cr=0x22800282 xer=0 ctr=0x8102b6100
r2=0x8102d2378 frame=0xe0005758b8
10  
KDB: enter: panic 

0xc0735e78 in doadump (textdump=16884644) at
/usr/src/sys/kern/kern_shutdown.c:393
393 savectx();  

(kgdb) bt   
#0  0xc0735e78 in doadump (textdump=16884644) at
/usr/src/sys/kern/kern_shutdown.c:393
#1  0xc0230394 in db_dump (dummy=, dummy2=, dummy3=,
dummy4=) at /usr/src/sys/ddb/db_command.c:575
#2  0xc0230028 in db_command (last_cmdp=,
cmd_table=, dopager=0)
at /usr/src/sys/ddb/db_command.c:482 
#3  0xc022fcd8 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:535
#4  0xc02343fc in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:253
#5  0xc079a548 in kdb_trap (type=, code=,
tf=0xc10a5370)
at /usr/src/sys/kern/subr_kdb.c:699 
#6  0xc0b8c6d8 in db_trap_glue (frame=) at
/usr/src/sys/powerpc/powerpc/trap.c:940
#7  
#8  0xc0799758 in kdb_enter (why=0xc0eabdc0 "panic",
msg=)
at /usr/src/sys/kern/subr_kdb.c:485 
#9  0xc073614c in vpanic (fmt=0xc0ea221f "kdb_sysctl_panic",
ap=)
at /usr/src/sys/kern/kern_shutdown.c:902
...


Note that a recent gdb/kgdb is needed.

The 'ps -M' command worked too:

# ps aux -M /var/crash/vmcore.last
USER PID %CPU %MEM   VSZ  RSS TT  STAT STARTEDTIME COMMAND
root   0  0.0  0.0 00  -  DLs  31Dec69 0:00.10 [kernel]   
root   1  0.0  0.0 11308 1108  -  DLs  31Dec69 0:00.02 [init] 
root   2  0.0  0.0 00  -  DL   31Dec69 0:00.00 [crypto]   
root   3  0.0  0.0 00  -  DL   31Dec69 0:00.00 [crypto returns 0] 
root   4  0.0  0.0 00  -  DL   31Dec69 0:00.00 [crypto returns 1]
root   5  0.0  0.0 00  -  DL   31Dec69 0:00.00 [crypto returns 2]
...
root 711  0.0  0.0 13456 3608  -  Ds   31Dec69 0:00.01 [login]
root 712  0.0  0.1 14828 4604  -  D31Dec69 0:00.04 [csh]
root 715  0.0  0.0 12108 2456  -  R+   31Dec69 0:00.00 [sysctl]


The STARTED field is invalid, but the otherwise the command output seems
correct.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #16 from Mark Millard  ---
Head -352175 added ET_DYN to _kvm_probe_elf_kernel
and ET_DYN is what started this.

As stands dump hangs on the old PowerMac G5s.
So I'm unable to produce such powerpc64 dumps
to see what the libkvm handling it like.

I gather that the main line of development is
on more modern hardware and is not seeing such
problems --so dumps are being used via libkvm
from what I can tell.

It appears that someone with a powerpc64
environment that can dump would have to check
on the status of this. I'm blocked at an
earlier stage.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #14 from Mark Millard  ---
(In reply to John Baldwin from comment #8)

With the following hacks I've been able to get
an output for the debug.minidump=0 based
vmcore.2 (2 GiBYte RAM dumped) for
powerpc (32-bit) FreeBSD via:

# ps -aux -M /var/crash/vmcore.2 -N /usr/lib/debug/boot/kernel/kernel.debug 
USERPID %CPU %MEM   VSZ   RSS TT  STAT STARTEDTIME COMMAND
root  0  0.0  0.0 0 0  -  DLs  31Dec69 0:00.11 [kernel]
root  1  0.0  0.0  5400   792  -  DLs  31Dec69 0:00.06 [init]
root  2  0.0  0.0 0 0  -  DL   31Dec69 0:00.00 [crypto]
root  3  0.0  0.0 0 0  -  DL   31Dec69 0:00.00 [crypto returns]
. . .
markmi 1086  0.0  0.2 14192  4168  -  D31Dec69 0:00.00 [sshd]
markmi 1087  0.0  0.1  7048  2812  -  Ds   31Dec69 0:00.00 [sh]
root   1088  0.0  0.1  7900  2660  -  D31Dec69 0:00.00 [su]
root   1089  0.0  0.1  7048  2800  -  D+   31Dec69 0:00.00 [sh]

(The STARTED column output is odd above.)

Be warned that I've not done much FreeBSD
coding and so am not familiar with the coding
standards and/or guidelines and just did
my own thing.

# svnlite diff /usr/src/lib/libkvm/kvm_private.c
Index: /usr/src/lib/libkvm/kvm_private.c
===
--- /usr/src/lib/libkvm/kvm_private.c   (revision 317820)
+++ /usr/src/lib/libkvm/kvm_private.c   (working copy)
@@ -128,7 +128,9 @@
 {

return (kd->nlehdr.e_ident[EI_CLASS] == class &&
-   kd->nlehdr.e_type == ET_EXEC &&
+   (  kd->nlehdr.e_type == ET_EXEC ||
+  kd->nlehdr.e_type == ET_DYN
+   ) &&
kd->nlehdr.e_machine == machine);
 }

Then in:

static int
_powerpc_kvatop(kvm_t *kd, kvaddr_t va, off_t *ofs)

I did:

# svnlite diff /usr/src/lib/libkvm/kvm_powerpc.c
Index: /usr/src/lib/libkvm/kvm_powerpc.c
===
--- /usr/src/lib/libkvm/kvm_powerpc.c   (revision 317820)
+++ /usr/src/lib/libkvm/kvm_powerpc.c   (working copy)
@@ -209,6 +209,53 @@
if (be32toh(vm->ph->p_paddr) == 0x)
return ((int)powerpc_va2off(kd, va, ofs));

+   // HACK in something for what I observe in
+   // a debug.minidump=0 vmcore.* for 32-bit powerpc
+   //
+   if (  be32toh(vm->ph->p_vaddr)  == 0x
+  && be32toh(vm->ph->p_paddr)  == 0
+  && be16toh(vm->eh->e_phnum)  == 1
+  ) {
+   // Presumes p_memsz is either unsigned
+   // 32-bit or is 64-bit, same for va .
+
+   if (be32toh(vm->ph->p_memsz) <= va)
+   return 0; // Like powerpc_va2off
+
+   // If ofs was (signed) 32-bit there
+   // would be a problem for sufficiently
+   // large postive memsz's and va's
+   // near the end --because of p_offset
+   // and dmphdrsz causing overflow/wrapping
+   // for some large va values.
+   // Presumes 64-bit ofs for such cases.
+   // Also presumes dmphdrsz+p_offset
+   // is non-negative so that small
+   // non-negative va values have no
+   // problems with ofs going negative.
+
+   *ofs =vm->dmphdrsz
+   + be32toh(vm->ph->p_offset)
+   + va;
+
+   // The normal return value overflows/wraps
+   // for p_memsz == 0x8000u when va == 0 .
+   // Avoid this by depending on calling code's
+   // loop for sufficiently large cases.
+   // This code presumes p_memsz/2 <= MAX_INT .
+   // 32-bit powerpc FreeBSD does not allow
+   // using more than 2 GiBytes of RAM but
+   // does allow using 2 GiBytes on 64-bit
+   // hardware.
+   //
+   if (  (int)be32toh(vm->ph->p_memsz) < 0
+  && va < be32toh(vm->ph->p_memsz)/2
+  )
+   return be32toh(vm->ph->p_memsz)/2;
+
+   return be32toh(vm->ph->p_memsz) - va;
+   }
+
_kvm_err(kd, kd->program, "Raw corefile not supported");
return (0);
 }

(Technically I combined this with my clang
targeting powerpc 32-bit testing by building
it as a clang based buildworld.)

I do not claim the code is appropriate for
FreeBSD use but it might get me closer to
investigating why production-style kernel
builds (gcc 4.2.1 based) panic on a pid 11
(idle process) thread every so often, even
when world was also gcc 4.2.1 based.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #13 from Mark Millard  ---
(In reply to Mark Millard from comment #12)

I found the "Raw core file not supported"
logic in /usr/src/lib/libkvm/kvm_powerpc.c :

static int
_powerpc_kvatop(kvm_t *kd, kvaddr_t va, off_t *ofs)
{
struct vmstate *vm;

vm = kd->vmst;
if (be32toh(vm->ph->p_paddr) == 0x)
return ((int)powerpc_va2off(kd, va, ofs));

_kvm_err(kd, kd->program, "Raw corefile not supported");
return (0);
}

where the usage was:

(gdb) step
_powerpc_kvatop (kd=0x41e14000, ofs=0xcaa0) at
/usr/src/lib/libkvm/kvm_powerpc.c:208

(gdb) print *kd
$11 = {arch = 0x41898118, program = 0x0, errp = 0x0, errbuf = 0x41e1400c "",
pmfd = 6, vmfd = -1, nlfd = 7, nlehdr = {e_ident = 0x41e14818
"\177ELF\001\002\001\t", e_type = 3, e_machine = 20, 
e_version = 1, e_entry = 1048800, e_phoff = 0, e_shoff = 36444532, e_flags
= 32768, e_ehsize = 52, e_phentsize = 0, e_phnum = 0, e_shentsize = 40, e_shnum
= 69, e_shstrndx = 65}, 
  resolve_symbol = 0, procbase = 0x0, argspc = 0x0, arglen = 0, argv = 0x0,
argc = 0, argbuf = 0x0, vmst = 0x41e22000, rawdump = 0, writable = 0,
vnet_initialized = 0, vnet_start = 0, vnet_stop = 0, 
  vnet_current = 0, vnet_base = 0, dpcpu_initialized = 0, dpcpu_start = 0,
dpcpu_stop = 0, dpcpu_maxcpus = 0, dpcpu_off = 0x0, dpcpu_curcpu = 0,
dpcpu_curoff = 0, pt_map = 0x0, pt_map_size = 0, 
  pt_sparse_off = 0, pt_sparse_size = 0, pt_popcounts = 0x0, pt_page_size = 0,
pt_word_size = 0}

(gdb) print *kd->vmst
$12 = {map = 0x41841000, mapsz = 84, dmphdrsz = 0, eh = 0x41841000, ph =
0x41841034}

(gdb) print *kd->vmst->ph
$13 = {p_type = 1, p_offset = 4096, p_vaddr = 4294967295, p_paddr = 0, p_filesz
= 2147483648, p_memsz = 2147483648, p_flags = 4, p_align = 4096}

(gdb) print *kd->vmst->eh
$14 = {e_ident = 0x41841000 "\177ELF\001\002\001?", e_type = 4, e_machine = 20,
e_version = 0, e_entry = 0, e_phoff = 52, e_shoff = 0, e_flags = 0, e_ehsize =
52, e_phentsize = 32, e_phnum = 1, 
  e_shentsize = 40, e_shnum = 0, e_shstrndx = 0}

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #12 from Mark Millard  ---
(In reply to Mark Millard from comment #11)

So trying:

ps -M /var/crash/vmcore.2 -N /usr/lib/debug/boot/kernel/kernel.debug

for a vmcore.2 based on: debug.minidump=0

things do not work well either. A hint is that
core.txt.2 says all over the place:

Raw corefile not supported

(for both /usr/local/bin/ based and
/usr/libexec/ based generation of
core.txt.2 from vmcore.2 ).

The result for ps is that:

struct kinfo_proc *
kvm_getprocs(kvm_t *kd, int op, int arg, int *cnt)

gets to:

if (KREAD(kd, nl[0].n_value, )) {
_kvm_err(kd, kd->program, "can't read nprocs");
return (0);
}

and calls the _kvm_err shown and
does not try to do any more.

(gdb) print *nl
$3 = {n_name = 0x41887179 "_nprocs", n_type = 9 '\t', n_other = 0 '\0', n_desc
= 0, n_value = 13942140}

13942140 = 0xD4BD7C

which is the right address (matching what
a live ddb reports for that kernel build
for nprocs [an address]).

But the vmcore.2 has 0x for
its VirtAddr and 0x0 for PhysAddr
(and Entry point):

# readelf -a /var/crash/vmcore.2
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 ff 00 00 00 00 00 00 00 00 
  Class: ELF32
  Data:  2's complement, big endian
  Version:   1 (current)
  OS/ABI:StandAlone
  ABI Version:   0
  Type:  CORE (Core file)
  Machine:   PowerPC 32-bit
  Version:   0
  Entry point address:   0
  Start of program headers:  52 (bytes into file)
  Start of section headers:  0 (bytes into file)
  Flags: 0
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 1
  Size of section headers:   40 (bytes)
  Number of section headers: 0 (0)
  Section header string table index: 0

Elf file type is CORE (Core file)
Entry point 0x0
There are 1 program headers, starting at offset 52

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x001000 0x 0x 0x8000 0x8000 R  
0x1000

There are no sections in this file.

There is no dynamic section in this file.


It appears that 0xD4BD7C+0x1000 == 0xD4CD7C
is the offset in the vmcore.2 file for
extracting nprocs and using:

cat /var/crash/vmcore.2 | hd | more

it looks correct (the 00 00 00 36):

00d4cd70  00 00 00 01 00 00 00 01  00 00 01 00 00 00 00 36  |...6|

(The surrounding area looks like in the
prior minidumps for what was around nprocs
and the 36 (hex) matches what ddb reported.)

So apparently libkvm does not deal with
this context.

/usr/local/bin/kgdb segmentation faulted
when attempted on vmcore.2 .

/usr/libexec/kgdb got:

Cannot access memory at address 0x0

instead.

[Both using /var/lib/debug/boot/kernel/kernel.debug .]

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #11 from Mark Millard  ---
(In reply to Mark Millard from comment #9)

[This note is limited to contexts with gcc
4.2.1 based kernels.]

Summary after avoiding a user error: looks
like there is a default of debug.minidump=1
that means that the process information is
not in the vmcore file. I'll have to generate
new cores with that disabled.

Details:

I really needed to use:

ps -M /var/crash/vmcore.7 -N /usr/lib/debug/boot/kernel/kernel.debug

because when I look at the vmcore.*'s I'm
not using the kernel that fails periodically.
(Not using the kernel build that I wanted to
use kgdb with to look at its crashes.)
(A debug kernel build works but a production
build of the same sources crashes in a
pid 11 thread [idle thread] eventually.

I manually

unload
boot kergcd

instead of using /boot/kernel/kernel when I
do not want the kernel to fail for what I'm
doing.

/boot/kernel/kernel
and
/usr/lib/debug/boot/kernel/kernel.debug

are a matching pair for the failing kernel.

truss shows where ps extracts the
nprocs figure and such. My own
calculations via looking at:

readelf -a /var/crash/vmcore.7 | more
and
readelf -a /usr/lib/debug/boot/kernel/kernel.debug

agrees with what I see in:

cat /var/crash/vmcore.7 | hd | more

The address shown in ddb matches
my calculations as well.

But to do this with matching files I had
to use some more recent vmcore.* files
because other experiments had updated
the kernel (and world).

So here is what I found based on having a
matching -N for the -M :

nprocs=52 (0x36)

(which is good) but when it gets into:

static int
kvm_proclist(kvm_t *kd, int what, int arg, struct proc *p,
struct kinfo_proc *bp, int maxcnt)

and its code:

for (; cnt < maxcnt && p != NULL; p = LIST_NEXT(, p_list))
{
memset(kp, 0, sizeof *kp);
if (KREAD(kd, (u_long)p, )) {
_kvm_err(kd, kd->program, "can't read proc at
%p", p);
return (-1);
}

the _kvm_err is being called for the first p value:

(gdb) print p
$4 = (struct proc *) 0x873c370

for which no VirtAddr/MemSiz combination
in the vmcore.9 file spans representing
that address:

# readelf -a /var/crash/vmcore.9 
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 ff 00 00 00 00 00 00 00 00 
  Class: ELF32
  Data:  2's complement, big endian
  Version:   1 (current)
  OS/ABI:StandAlone
  ABI Version:   0
  Type:  CORE (Core file)
  Machine:   PowerPC 32-bit
  Version:   0
  Entry point address:   0
  Start of program headers:  52 (bytes into file)
  Start of section headers:  0 (bytes into file)
  Flags: 0
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 3
  Size of section headers:   40 (bytes)
  Number of section headers: 0 (0)
  Section header string table index: 0

Elf file type is CORE (Core file)
Entry point 0x0
There are 3 program headers, starting at offset 52

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x001000 0x008fe000 0x 0x6d7000 0x6d7000 R   0x1000
  LOAD   0x6d8000 0xd0005000 0x 0x18000 0x18000 R   0x1000
  LOAD   0x6f 0xd001d000 0x 0x01000 0x01000 R   0x1000

There are no sections in this file.

There is no dynamic section in this file.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #10 from Mark Millard  ---
(In reply to John Baldwin from comment #8)

The bt that I included shows libstdc++ in use
inside /usr/local/bin/gdb, not libc++ . This
is because /usr/local/bin/gdb was built under
a gcc 4.2.1 world via the gcc 4.2.1 compiler
(no clang present at the time).

# ldd /usr/local/bin/gdb
/usr/local/bin/gdb:
libreadline.so.6 => /usr/local/lib/libreadline.so.6 (0x42ba4000)
libncurses.so.8 => /lib/libncurses.so.8 (0x42bfc000)
libkvm.so.7 => /lib/libkvm.so.7 (0x42c55000)
libutil.so.9 => /lib/libutil.so.9 (0x42c77000)
libthr.so.3 => /lib/libthr.so.3 (0x42c9b000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x42cd6000)
libm.so.5 => /lib/libm.so.5 (0x42cf1000)
libpython2.7.so.1 => /usr/local/lib/libpython2.7.so.1 (0x42d28000)
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x42f12000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x42f4b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x42f83000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x43095000)
libc.so.7 => /lib/libc.so.7 (0x430b5000)
libelf.so.2 => /lib/libelf.so.2 (0x4325a000)

(Avoiding delete-old-libs keeps libraries around
that otherwise would not exist when I context switch.
gcc-4.2.1-based and clang-based are based on the
same /usr/src built two ways.)

/usr/local/bin/gdb does use C++ exceptions internally,
at least for some things.

It is the original a.out that has clang-based bindings
(libcxxrt.so.1 and libc++.so.1):

# ldd ~/c_tests/a.out
/root/c_tests/a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x4183b000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x4191e000)
libm.so.5 => /lib/libm.so.5 (0x41949000)
libc.so.7 => /lib/libc.so.7 (0x4198)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x41b33000)

FYI:

# ldd /usr/libexec/gdb 
/usr/libexec/gdb:
libm.so.5 => /lib/libm.so.5 (0x41afa000)
libncursesw.so.8 => /lib/libncursesw.so.8 (0x41b31000)
libgnuregex.so.5 => /usr/lib/libgnuregex.so.5 (0x41b96000)
libc.so.7 => /lib/libc.so.7 (0x41bba000)

(So fewer dependencies to have working well for it
to be "working". No C++ library use.)


As for #13, *info, and *lmo:

#13 0x019b42b8 in solib_svr4_r_map (info=0x44002084) at solib-svr4.c:913
#14 0x019b4648 in svr4_current_sos_direct (info=0x436232c0) at
solib-svr4.c:1494

#14 has the right address for info. #13 is reporting the
R30 value as the info address for some reason (R30 is
frequently used for PIC support in powerpc land).
svr4_current_sos_direct passes its info value to
solib_svr4_r_map unchanged.

(gdb) up 14
#14 0x019b4648 in svr4_current_sos_direct (info=0x436232c0) at
solib-svr4.c:1494
1494  lm = solib_svr4_r_map (info);
Current language:  auto; currently c++
(gdb) print *info
$1 = {debug_base = 4, debug_loader_offset_p = 0, debug_loader_offset = 0,
debug_loader_name = 0x0, main_lm_addr = 0, interp_text_sect_low = 0,
interp_text_sect_high = 0, interp_plt_sect_low = 0, 
  interp_plt_sect_high = 0, using_xfer = 0, probes_table = 0x0, solib_list =
0x0}

(gdb) down
#13 0x019b42b8 in solib_svr4_r_map (info=0x44002084) at solib-svr4.c:913
913 ptr_type);
(gdb) print *lmo
$2 = {r_version_offset = 0, r_version_size = 4, r_map_offset = 4, r_brk_offset
= 8, r_ldsomap_offset = 20, link_map_size = 20, l_addr_offset = 0, l_ld_offset
= 8, l_next_offset = 12, 
  l_prev_offset = 16, l_name_offset = 4}

This is via /usr/libexec/gdb on the same system build that
a.out was produced and tested on (clang based).


Other notes:

/usr/local/bin/gdb segmentation faults looking at its
own core file, much like it does looking at the a.out
core file.

I will note that in comment #3's list of differences it was
/usr/libexec/gdb that got things like the rates for interrupts
correct. (Both gdb's listed the same counts --but got very
different rates. /usr/local/bin/gdb showed to rates that were
too large by a lot.) Similar points go for other parts of the
diff: /usr/libexec/gdb got more correct. This was a gcc 4.2.1
based environment, not clang-based.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #9 from Mark Millard  ---
(In reply to John Baldwin from comment #5)

As for ps -M /var/crash/vmcore.7 listing no
processes:

main uses kvm_getprocs, which in turn eventually
does:

if (KREAD(kd, nl[0].n_value, )) {
_kvm_err(kd, kd->program, "can't read nprocs");
return (0);
}

but that ends up with:

(gdb) print nprocs
$2 = 12873340

(I checked the code and "info reg" and the value
matched.)

So things are already well messed up here.

That in turn ends up used in:

size = nprocs * sizeof(struct kinfo_proc);
kd->procbase = (struct kinfo_proc *)_kvm_malloc(kd,
size);
if (kd->procbase == NULL)
return (0);

which succeeds but later there is:

nprocs = kvm_deadprocs(kd, op, arg, nl[1].n_value,
  nl[2].n_value, nprocs);
if (nprocs <= 0) {
_kvm_freeprocs(kd);
nprocs = 0;
}

which in kvm_deadprocs gets to:

if (KREAD(kd, a_allproc, )) {
_kvm_err(kd, kd->program, "cannot read allproc");
return (-1);
}
acnt = kvm_proclist(kd, what, arg, p, bp, maxcnt);
if (acnt < 0)
return (acnt);

where:

static int
kvm_proclist(kvm_t *kd, int what, int arg, struct proc *p,
struct kinfo_proc *bp, int maxcnt)
{
int cnt = 0;
. . .

is used via:

kvm_proclist (kd=0x41e14000, what=5, arg=0, p=0x0, bp=0x4200,
maxcnt=12873340)

and the internal kvm_proclist loop no-ops because of p:

for (; cnt < maxcnt && p != NULL; p = LIST_NEXT(, p_list))
{

So no process is listed. After the loop is:

return (cnt);
}

And that means:

nprocs = kvm_deadprocs(kd, op, arg, nl[1].n_value,
  nl[2].n_value, nprocs);
if (nprocs <= 0) {
_kvm_freeprocs(kd);
nprocs = 0;
}

ends up with nprocs==0 and kd is freed, hopefully including
kd->procbase being freed (I did not look).

But overall: at least one KREAD gets back a junk figure.

And with that I think I will stop for this note.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #8 from John Baldwin  ---
Can you pop up to frame 13 (solib_svr4_r_map) and 'p *info' and 'p *lmo'?  The
lack of working exceptions from clang (which appears to be the source of the
coredump in gdb itself) might be problematic though.  gdb might very well
depend on working exceptions to work properly.  The current gdb7.12.1 can be
compiled with gcc4.2.1 still which might work better than compiling with clang.
 The next gdb release (8.0) requires C++11 which will need an external gcc or
fully functional clang.  I've been using mips-gcc to build gdb 'master' for
FreeBSD/mips just fine against a MIPS world built via mips-xtoolchain-gcc (both
32-bit and 64-bit).

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #7 from Mark Millard  ---
(In reply to John Baldwin from comment #5)

This note is for the /usr/local/bin/gdb crash.

As for building ports with debug information, I use
as a default context:

# svnlite diff /usr/ports/Mk/
Index: /usr/ports/Mk/bsd.port.mk
===
--- /usr/ports/Mk/bsd.port.mk   (revision 440115)
+++ /usr/ports/Mk/bsd.port.mk   (working copy)
@@ -1639,7 +1639,11 @@
 STRIP_CMD= ${TRUE}
 .endif
 DEBUG_FLAGS?=  -g
+.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG)
+CFLAGS:=   ${CFLAGS} ${DEBUG_FLAGS}
+.else
 CFLAGS:=   ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+.endif
 .if defined(INSTALL_TARGET)
 INSTALL_TARGET:=   ${INSTALL_TARGET:S/^install-strip$/install/g}
 .endif

and:

# more /etc/make.conf 
WANT_QT_VERBOSE_CONFIGURE=1
#
DEFAULT_VERSIONS+=perl5=5.24 gcc=6
WRKDIRPREFIX=/usr/obj/portswork
#
# From a local /usr/ports/Mk/bsd.port.mk extension:
ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=
#
.if ${.CURDIR:M*/devel/llvm*}
#WITH_DEBUG=
.elif ${.CURDIR:M*/www/webkit-qt5*}
#WITH_DEBUG=
.else
WITH_DEBUG=
.endif
WITH_DEBUG_FILES=
MALLOC_PRODUCTION=

(WITH_DEBUG= makes level/llvm40 and www/webkit-qt5
massively large, which I avoid. It has been years
since I've built or used www/webkit-qt5, however.)

An example core file bt for /usr/local/bin/gdb getting
its own segmentation fault is as follows. Note #11 and
its memaddr=8 . (#0-#10 are the attempted handling of
the bad (and incorrect?) address, but the attempt got
its own failure.)

#0  0x430935d0 in _Unwind_SetGR (context=, index=, val=1130509136) at unwind-dw2-fde.h:162
162 {
Cannot find new threads: generic error
(gdb) bt
#0  0x430935d0 in _Unwind_SetGR (context=, index=, val=1130509136) at unwind-dw2-fde.h:162
#1  0x432c53b8 in __gxx_personality_v0 (version=,
actions=6, exception_class=, ue_header=0x43623350,
context=0xd0a0)
at
/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:681
#2  0x43094234 in _Unwind_RaiseException_Phase2 (exc=,
context=) at unwind.inc:66
#3  0x43093e10 in _Unwind_RaiseException (exc=0xd0a0) at unwind.inc:135
#4  0x432c4778 in __cxa_throw (obj=, tinfo=, dest=) at
/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:71
#5  0x01c9f398 in throw_exception_cxx (exception={reason = RETURN_ERROR, error
= MEMORY_ERROR, message = 0x43748400 "Cannot access memory at address 0x8"}) at
./common/common-exceptions.c:303
#6  0x01c9f42c in throw_exception (exception=Cannot access memory at address
0x0
) at ./common/common-exceptions.c:317
#7  0x01c9f4f8 in throw_it (reason=1130509136, error=MEMORY_ERROR, fmt=, ap=) at ./common/common-exceptions.c:373
#8  0x01c9f5ec in throw_verror (error=, fmt=, ap=) at ./common/common-exceptions.c:379
#9  0x01c9f65c in throw_error (error=, fmt=) at ./common/common-exceptions.c:394
#10 0x01bedcf8 in memory_error (err=, memaddr=) at corefile.c:237
#11 0x01bedfbc in read_memory_object (object=TARGET_OBJECT_MEMORY, memaddr=8,
myaddr=0xd940 "???`C\027\024\033???p", len=)
at corefile.c:261
#12 0x01bee1b0 in read_memory_typed_address (addr=,
type=0x438e0018) at corefile.c:400
#13 0x019b42b8 in solib_svr4_r_map (info=0x44002084) at solib-svr4.c:913
#14 0x019b4648 in svr4_current_sos_direct (info=0x436232c0) at
solib-svr4.c:1494
#15 0x019b4e40 in svr4_current_sos () at solib-svr4.c:1528
#16 0x01c71264 in update_solib_list (from_tty=26952375, target=) at solib.c:767
#17 0x01c71b4c in solib_add (pattern=0x0, from_tty=0, target=0x2d43100,
readsyms=1) at solib.c:994
#18 0x01b33eb4 in post_create_inferior (target=0x2d43100, from_tty=1) at
infcmd.c:461
#19 0x01ade424 in core_open (arg=, from_tty=1) at
corelow.c:407
#20 0x01bee65c in core_file_command (filename=0xde21
"/var/crash/a.out.29973.core", from_tty=1) at corefile.c:77
#21 0x01b583b8 in catch_command_errors (command=0x1bee610
, arg=, from_tty=1) at
main.c:375
#22 0x01b593f0 in captured_main (data=) at main.c:1081
#23 0x01b596ac in gdb_main (args=0xdcb8) at main.c:1159
#24 0x01890d54 in main (argc=, argv=0xdcfc) at
gdb.c:38
Current language:  auto; currently minimal

The original program /usr/local/bin/gdb was looking at was a simple
C++ exception handling test compiled by system-clang++ on a world
built by system-clang. (Tied to my getting evidence of things for
the 2 folks working on things for targeting powerpc via clang.)
That original a.out gets its own segmentation fault due to what
clang generated.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #6 from Mark Millard  ---
(In reply to John Baldwin from comment #5)

I've used both gdb's as well but I've had more
occasions when system's gdb worked and ports
did not than the other way around (when there
is a distinction). (Historically, not just
now.)

Okay I'll poke at ps -M and the /usr/local/bin/gdb
crash.

Be warned: I'm also currently evidence-gathering
for two folks working on the clang powerpc and/or
powerpc64 targeting support so my FreeBSD
time is split.

This also leads to context switching between a
world built with gcc 4.2.1 and one built with
clang. If I'm interrupted I can forget to switch
and, for example, end up seeing the clang issues
without initially noticing why (clang built
system libraries, for example).

I'll rerun the /usr/local/bin/gdb test explicitly
on a gcc 4.2.1 built world just in case that
happened yesterday.

(clang generates powerpc and powerpc64 "code" that
has handling of thrown-C++-exceptions completely
broken, leading to segmentation faults while trying
to reach landing-pad code. "Code": incomplete dwarf
information.)

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #5 from John Baldwin  ---
I would start with trying to debug why 'ps -M' doesn't work by stepping through
'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. 
Alternatively, you can grab the a.out and core file from a ppc system and debug
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 gdb7
using a native gdb7 on amd64.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #4 from Mark Millard  ---
A not as libkvm tied note about which gdb
works better for 32-bit powerpc in at
least some contexts:

I took an a.out (from clang++ 
targeting powerpc) and tried
/usr/local/bin/gdb and /usr/libexec/gdb
on a core it generated:

# gdb a.out /var/crash/a.out.29973.core 
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
. . .
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
Segmentation fault (core dumped)

(gdb itself Segmentation faulted.)

# /usr/libexec/gdb a.out /var/crash/a.out.29973.core
GNU gdb 6.1.1 [FreeBSD]
. . .
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libc++.so.1...Reading symbols from
/usr/lib/debug//usr/lib/libc++.so.1.debug...done.
. . .
Loaded symbols for /libexec/ld-elf.so.1
#0  0x41b355d0 in _Unwind_SetGR (context=, index=, val=1105281072) at unwind-dw2-fde.h:162
162 {
(gdb) bt
#0  0x41b355d0 in _Unwind_SetGR (context=, index=, val=1105281072) at unwind-dw2-fde.h:162
#1  0x4192e370 in __gxx_personality_v0 (version=,
actions=, exceptionObject=0x41e14030, context=0xd5c0)
at /usr/src/contrib/libcxxrt/exception.cc:1203
#2  0x41b36234 in _Unwind_RaiseException_Phase2 (exc=,
context=) at unwind.inc:66
#3  0x41b35e10 in _Unwind_RaiseException (exc=0xd5c0) at unwind.inc:135
#4  0x4192d870 in __cxa_throw (thrown_exception=,
tinfo=, dest=) at
/usr/src/contrib/libcxxrt/exception.cc:774
#5  0x01800954 in main () at exception_test.cpp:5
Current language:  auto; currently minimal

The same thing happens for running the a.out inside gdb:
/usr/local/bin/gdb gets a Segmentation fault of its own
and /usr/libexec/gdb works, including allowing the bt.

Historically I've primarily used the system gdb to do my
analysis of clang's code generation problems for targeting
powerpc. Including when I looked at gcc 4.2.1 generated
code for comparison. The above sort of thing is an example
of why.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #3 from Mark Millard  ---
(In reply to Mark Millard from comment #2)

An FYI based on my ET_DYN test hack in
libkvm:

I've gotten some more panics with the libkvm
change in place. This makes the new core.txt.*
more interesting.

Initially here I just emphasize where
/usr/local/bin/gdb and /usr/libexec/gdb use
in crashinfo got different
results, picking an example vmcore file.

3c3
< Tue May  9 14:21:24 PDT 2017
---
> Tue May  9 14:58:07 PDT 2017
5c5
< FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r317820M  powerpc
---
>  FBSDG4S   
9,24c9,15
< GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
. . .
< This GDB was configured as "powerpc-portbld-freebsd12.0".
. . .
< Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
< done.
---
> GNU gdb 6.1.1 [FreeBSD]
. . .
> This GDB was configured as "powerpc-marcel-freebsd"...kgdb: kvm_read: 
25a17
> 
38,39c30,31
< No thread selected.
< (kgdb) No thread selected.
---
> 0x in ?? ()
> (kgdb) #0  0x in ?? ()
113,115c105,107
< cpu0:decrementer  140155   1757
< irq0: iichb0  104190   1306
< irq8: bge0  4043 51
---
> cpu0:decrementer  140155117
> irq0: iichb0  104190 87
> irq8: bge0  4043  3
117c109
< irq70: ohci0 ohci1+22390281
---
> irq70: ohci0 ohci1+22390 19
122c114
< irq27: iichb1 85  1
---
> irq27: iichb1 85  0
124,125c116,117
< irq10: atapci0  5778 72
< irq38: ata0 8593108
---
> irq10: atapci0  5778  5
> irq38: ata0 8593  7
127,132c119,124
< irq53: smudoorbell030226379
< irq124: IPI   237384   2976
< cpu3:decrementer   32632409
< cpu1:decrementer   33061415
< cpu2:decrementer   34929438
< Total 653474   8193
---
> irq53: smudoorbell030226 25
> irq124: IPI   237384197
> cpu3:decrementer   32632 27
> cpu1:decrementer   33061 27
> cpu2:decrementer   34929 29
> Total 653474543
143c135
< Device  512-blocks UsedAvail Capacity
---
> Device  1K-blocks UsedAvail Capacity
578,586c570,598
<  7f032b8 tcp4   0  0 *.111  *.*LISTEN
<  7f03570 tcp6   0  0 *.111  *.*LISTEN
<  7d56348 udp6   0  0 *.**.*
<  5ea8c08 udp4   0  0 *.901  *.*
<  5ea8d20 udp4   0  0 *.111  *.*
<  5ea8e38 udp6   0  0 *.903  *.*
<  5ea9000 udp6   0  0 *.111  *.*
<  5ea9118 udp4   0  0 *.514  *.*
<  5ea9230 udp6   0  0 *.514  *.*
---
>  8f93000 tcp4   0  0 192.168.1.7.22 192.168.1.106.4955 ESTABLISHED
>  a8732b8 tcp4   0  0 127.0.0.1.25   *.*LISTEN
>  8fac570 tcp4   0  0 *.22   *.*LISTEN
>  8fac828 tcp6   0  0 *.22   *.*LISTEN
>  8fb9570 tcp6   0  0 *.2049 *.*LISTEN
>  8fb9828 tcp4   0  0 *.2049 *.*LISTEN
>  8facae0 tcp4   0  0 *.762  *.*LISTEN
>  8fad000 tcp6   0  0 *.762  *.*LISTEN
>  8f932b8 tcp4   0  0 *.111  *.*LISTEN
>  8f93570 tcp6   0  0 *.111  *.*LISTEN
>  8cbc8c0 udp4   0  0 127.0.0.1.123  *.*
>  8cbc9d8 udp6   0  0 fe80::1%lo0.123*.*
>  8cbcaf0 udp6   0  0 ::1.123*.*
>  8cbcc08 udp4   0  0 192.168.1.7.123*.*
>  8cbcd20 udp6   0  0 2601:1c0:4301:25.1 *.*
>  8cbce38 udp6   0  0 fe80::214:51ff:f.1 *.*
>  8cbd000 udp4   0  0 *.123  *.*
>  8cbd118 udp6   0  0 *.123  *.*
>  62ad000 udp6   0  0 *.2049 *.*
>  62ad118 udp4   0  0 *.2049 *.*
>  8cbd230 udp4   0  0 *.762  *.*
>  8cbd348 udp6   0  0 *.762  *.*  

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #2 from Mark Millard  ---
(In reply to John Baldwin from comment #1)

The ps -M result for using:

# svnlite diff /usr/src/lib
Index: /usr/src/lib/libkvm/kvm_private.c
===
--- /usr/src/lib/libkvm/kvm_private.c   (revision 317820)
+++ /usr/src/lib/libkvm/kvm_private.c   (working copy)
@@ -128,7 +128,9 @@
 {

return (kd->nlehdr.e_ident[EI_CLASS] == class &&
-   kd->nlehdr.e_type == ET_EXEC &&
+   (  kd->nlehdr.e_type == ET_EXEC ||
+  kd->nlehdr.e_type == ET_DYN
+   ) &&
kd->nlehdr.e_machine == machine);
 }

on powerpc (head -r317820 variant) is:

# ps -M /var/crash/vmcore.7
PID TT  STAT TIME COMMAND

I.e., the vmcore.* file is not rejected but no
actual list of processes is generated. This is
true of the other 6 vmcore.* 's that I have
around as well.

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

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

John Baldwin  changed:

   What|Removed |Added

 CC||j...@freebsd.org
 Status|New |Open

--- Comment #1 from John Baldwin  ---
I will work on fixing libkvm.  Mark, can you verify that if you just replace
'ET_EXEC' with 'ET_DYN' as a hack that 'ps -M' works?

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

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

[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"