Hi, Alexander and Sven, I just got around to testing drgn on s390x on 6.10-rc4, and it appears to be broken. I bisected it to commit 56b1069c40c7 ("s390/boot: Rework deployment of the kernel image") and narrowed it down to an issue with the KERNELOFFSET value reported in vmcoreinfo. On my test kernel, the ELF symbol for init_task is 0xc96f00: $ eu-readelf -s build/vmtest/s390x/kernel-6.10.0-rc4-vmtest30.1default/build/vmlinux | grep ' init_task$' 72273: 0000000000c96f00 4352 OBJECT GLOBAL DEFAULT 18 init_task And the address in the loaded kernel is 0x3ffffeaaf00: # grep ' init_task$' /proc/kallsyms 000003ffffeaaf00 D init_task 0x3ffffeaaf00 - 0xc96f00 is 0x3ffff214000 However, this doesn't match the value of KERNELOFFSET in vmcoreinfo: # eu-readelf -n /proc/kcore | grep KERNELOFFSET KERNELOFFSET=3ffff314000 It's off by 0x100000. This causes drgn to compute the wrong addresses for all global variables. For context, I'm testing using QEMU emulation on an x86-64 host. Note that it logs "KASLR disabled: CPU has no PRNG" early during boot. My exact setup is: $ git clone https://github.com/osandov/drgn.git $ cd drgn $ python3 -m vmtest.rootfsbuild -a s390x --build-drgn $ python3 -m vmtest.vm -k 's390x:6.10.*' bash -i # python3 -m drgn >>> prog['init_task'].comm (char [16])"" That should be printing "swapper/0". Any ideas what's going on here? Thanks! Omar