qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4


From: BALATON Zoltan
Subject: Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4
Date: Wed, 12 Jan 2022 15:44:17 +0100 (CET)

Hello,

On Wed, 12 Jan 2022, John Paul Adrian Glaubitz wrote:
Hi Zoltan!

On 10/26/21 00:40, BALATON Zoltan wrote:
On Tue, 26 Oct 2021, John Paul Adrian Glaubitz wrote:
Hi Zoltan!

On 10/23/21 15:22, BALATON Zoltan wrote:
You either need to strip the kernel with "strip vmlinux" or use the image from 
arch/sh/
boot/zImage.

I've actually used that kernel but looked at the wrong uncompressed size, it's 
indeed just
9.2MB when stripped so that should work. I was trying to debug further and 
found two problems:

Commit abb0cd93494 (accel/tcg: Split out log_cpu_exec) seems to have broken 
-singlestep -d in_asm,cpu
output with sh after a delay slot. Since that commit I get:
(...)
This seems to take a wrong turn at the delayed branch and somehow ends up at 
0x8c800964 instead of
0x8c801528 but I'm not sure where to look firther why. I'm cc-ing Richard for 
both the -d cpu and
this hoping he has some more insight.

Shall we open a bug report?

Well, we don't know yet what to put in the bug report apart from there is some 
bug somewhere. That's
not too useful. I now understand that the -d output is not showing already 
translated TBs (I knew this
but most of the time with -singlestep it gives good results anyway) but here it 
runs the loops without
further output then we only see the first loop iteration and the end result. So 
the problem is not that
it goes to 0x8c800964 as I think that's part of the loop for decompressing the 
kernel but it seems
something is overwriting 0x8c800964 while it still expects to run code from 
there but I don't know what
and why. One way to find could be to disassemble the kernel code and compare 
that with the -d output and
check every instruction manually but that takes a lot of time or if you have a 
cross debugger you could
try attaching that to QEMU and try to debug it that way but I don't have that 
either. Any other idea how
to find out what is happening?

Robert Święcki (CC'ed) found out that disabling tracing support makes Debian's 
kernel bootable [1].

Not sure if this is a kernel bug or a QEMU bug then. Does QEMU have any support 
for kernel tracing?

Adrian

[1] https://marc.info/?l=linux-sh&m=164193147916418&w=2

I don't think there's any support in QEMU that interacts with kernel tracing. I think more likely is that disabling this option either avoids some code path in the kernel where the problem happens or it changes the memory layout (e.g. making the kernel take less space) so it does not overwrite the part where it crashes (if it's really a problem with writing to wrong address it may still corrupt something else but that may not cause immediate crash). So while it boots it may still have a problem later if it happens to write to used memory. Best way would be to debug with cross debugger and find where exactly it's crashing and find out why but I don't have a cross debugger for SH4 at the moment nor time to look into this.

Regards,
BALATON Zoltan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]