[Crash-utility] Re: [PATCH v6 1/5] ppc64: correct gdb passthroughs by implementing machdep->get_cpu_reg

On 2024/01/24 15:57, HAGIO KAZUHITO(萩尾 一仁) wrote: > Is it possible to upload a sample ppc64le vmcore and vmlinux somewhere > off-list? I would like to check the behavior at my end, probably > ppc64le vmcores can be processed by x86_64 crash for ppc64 vmcore. Thanks for the sample vmlinux and vmcore. I'm still reviewing the patches and "gdb bt" looks good to me, but it looks like "gdb info threads" calls GETBUF() too much. and the next same command fails. $ crash-ppc64 vmlinux vmcore ... crash-ppc64> gdb info threads Id Target Id Frame 1 CPU 0 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 2 CPU 1 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 3 CPU 2 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 ... 42 CPU 41 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 * 43 CPU 42 0xc00000000005ae44 in crash_fadump (regs=0x0, str=0xc000000002c0a6a0 <buf> "sysrq triggered crash") at arch/powerpc/kernel/fadump.c:728 44 CPU 43 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 ... 54 CPU 53 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 55 CPU 54 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 buf_1K_used: 50 buf_2K_used: 10 buf_4K_used: 2 buf_8K_used: 0 buf_32K_used: 3 ... malloc_bp[1997]: 8f3db90 malloc_bp[1998]: 8f41ba0 malloc_bp[1999]: 8f45bb0 smallest: 24 largest: 2883584 embedded: 2003 max_embedded: 2003 mallocs: 2162 frees: 162 reqs/total: 2228/41701642 average size: 18717 gdb: cannot allocate any more memory! crash-ppc64> crash-ppc64> gdb info threads ui-out.c:357: internal-error: tables cannot be nested; table_begin found before previous table_end. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) Doesn't this happen on ppc64 machines? There might be lack of FREEBUF() somewhere.