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

[John Paul Adrian Glaubitz]

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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913