From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 91664C433EF for ; Wed, 12 Jan 2022 11:52:43 +0000 (UTC) Received: from localhost ([::1]:59642 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n7cBG-0006de-IW for qemu-devel@archiver.kernel.org; Wed, 12 Jan 2022 06:52:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7bnB-0002mM-Sa for qemu-devel@nongnu.org; Wed, 12 Jan 2022 06:27:49 -0500 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]:42179) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7bn5-0003NB-Un for qemu-devel@nongnu.org; Wed, 12 Jan 2022 06:27:49 -0500 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.94) with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from ) id 1n7bmk-001wWv-Py; Wed, 12 Jan 2022 12:27:22 +0100 Received: from p57bd9010.dip0.t-ipconnect.de ([87.189.144.16] helo=[192.168.178.81]) by inpost2.zedat.fu-berlin.de (Exim 4.94) with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (envelope-from ) id 1n7bmk-003wRc-Jh; Wed, 12 Jan 2022 12:27:22 +0100 Message-ID: Date: Wed, 12 Jan 2022 12:27:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4 Content-Language: en-US To: BALATON Zoltan References: <4882e4cc-6754-1c8a-a8ae-a2ceeca115fb@physik.fu-berlin.de> <013d782d-0d7c-8204-cab2-08102a7d80f4@physik.fu-berlin.de> <3c524162-e83-a9b3-1e28-2aa28dbefa76@eik.bme.hu> <9189dbe7-cf92-19c7-dee5-b707262964d1@physik.fu-berlin.de> <3f483f63-9e68-b1da-01ab-a1e05dcf45aa@physik.fu-berlin.de> <378d863-abbb-57b7-d624-ce1ca81d09c@eik.bme.hu> <105383e6-9dab-e2bd-ffe2-fead5555f37c@physik.fu-berlin.de> <82c6635-68c7-9b51-3f6c-7555dfb7958c@eik.bme.hu> From: John Paul Adrian Glaubitz In-Reply-To: <82c6635-68c7-9b51-3f6c-7555dfb7958c@eik.bme.hu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Original-Sender: glaubitz@physik.fu-berlin.de X-Originating-IP: 87.189.144.16 Received-SPF: pass client-ip=130.133.4.66; envelope-from=glaubitz@zedat.fu-berlin.de; helo=outpost1.zedat.fu-berlin.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Richard Henderson , QEMU Developers , =?UTF-8?Q?Robert_=c5=9awi=c4=99cki?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 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