Kazuhito Hagio

Hmm, I tried to apply the patch to crash, but it looks pretty hard for me because it got changed from C into C++ and I'm also not an expert...

I have not found any good workaround or fix for this issue so far. Please use `rd` and `struct` commands instead of `p` for now.

I cannot reproduce that with the latest crash 7750e61fdb2a with crash-gcore v1.6.4 or the latest, at least. ``` crash> extend extensions/crash-gcore-command-1.6.4/gcore.so ./extensions/crash-gcore-command-1.6.4/gcore.so: shared object loaded ```

Not reproducible at my environment. Can you please look into what is wrong on your environment?

oh I missed that it's arm64, I tested on x86_64. Anyway, how about consulting its maintainer first? https://github.com/fujitsu/crash-gcore

Is there any error that indicates the cause? Debian has its crash, is there any helpful information for build? For example, https://packages.debian.org/en/sid/crash -> crash_8.0.0-1.dsc ``` Build-Depends: debhelper (>= 13), dpkg-dev...

> make target=X86_64 -j16 ---- build fail fwiw, the `make -j` option was supported at crash-8.0.1.

> so, kernel must configurate CONFIG_KEXEC=y to use bt command to analyze dumpfile for ARM/ARM64? Looks so in the current implementation. I'm not familiar with ramdump and not sure if...

There may be Xen users on the crash-utility mailing list [1] as said in the linked comment, I'd suggest to post your query to the list. [1] https://www.redhat.com/mailman/listinfo/crash-utility

A good news, a Xen developer posted a patchset that fixes several Xen issues, probably related to this. Could you try it? https://listman.redhat.com/archives/crash-utility/2023-March/010544.html There is a branch that has the...