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

[BALATON Zoltan]

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?

Regards,
BALATON Zoltan