From: Markus Duft <markus.duft@salomon.at>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: Debugging a 64-bit kernel in qemu
Date: Mon, 03 Jan 2011 14:12:10 +0100 [thread overview]
Message-ID: <4D21CB2A.3000802@salomon.at> (raw)
In-Reply-To: <4D21C85A.5070207@web.de>
On 01/03/2011 02:00 PM, Jan Kiszka wrote:
> [ please keep CCs ]
>
> Am 03.01.2011 13:27, Markus Duft wrote:
>> On 01/03/2011 01:15 PM, Markus Duft wrote:
>>> On 01/03/2011 12:15 PM, Jan Kiszka wrote:
>>> [snip]
>> [snip]
>>> actually, i find that Ted Harkington was right: in 0.11.1 i can debug 32 bit code with qemu-system-x86_64 well enough (which means i debugged all the 32 bit part of my kernel without ever seen _any_ problem/non-working feature/whatever). wouldn't it be better to have 64 bit debugging working in the 64 bit version, with 32 bit mode working mostly (with whatever small issues), rather than just completely dooming 64 bit debugging...?
>>>
>>
>> owh - spoke too soon. there must be more to it: i tried reverting 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1, which restores ability to debug my 64 bit kernel just fine, but now i get the packet too long when trying to debug 32 bit code....
>
> Hmm, that's new. You definitely loose stack unwinding when using the
> wrong mode, thus source-level debugging.
hmmm... ok - that could be. my "source" in that case is all assembly for the 32 bit part ;) i didn't have such a close look at stack unwinding, as i'm all in one single 32 bit procedure. the next call is already a far call to 64 bit mode, which re-sets the stack anyway.
>
> I thought that thread suggested to set the arch explicitly, maybe I
> misremembered that:
>
> set arch i386:x86_64
> tar rem :1234
arch is automatically at x86_64, as i start gdb giving it my elf64 kernel to load (which switches gdb to x86_64). however the first few instructions are 32 bit, switching to long mode then.
>
> If that is required, you probably load a 32-bit binary into gdb that
> also contains 64-bit code in some section. I guess this is even more
> confusing for gdb.
the other way round: i have a elf64 binary, containing all 64 bit code, but with exactly _one_ section containing 32 bit bootstrap code, which switches to long mode.
>
>>
>> wouldn't it be possible to implement some kind of explicit switch with qemu in the meantime, so i can choose what bitness i want to debug? I know, it's a problem with gdb under the hood, but still - it's really uncool debugging doesn't work in either of the two cases.
>
> Wasn't required so far. If you debug in either mode, "set arch" should
> do the job. If you have to debug across mode switches, that knob won't
> help anyway.
that definitely doesn't help in either of my cases... :( behaviour stays the same, no matter if i'm currently breaking in 32 bit or 64 bit code, and setting either architecture in any of the situations.
Regards, Markus
>
> Jan
>
prev parent reply other threads:[~2011-01-03 13:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-03 10:27 [Qemu-devel] Debugging a 64-bit kernel in qemu Markus Duft
2011-01-03 11:15 ` [Qemu-devel] " Jan Kiszka
2011-01-03 12:15 ` Markus Duft
2011-01-03 12:27 ` Markus Duft
2011-01-03 13:00 ` Jan Kiszka
2011-01-03 13:12 ` Markus Duft [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D21CB2A.3000802@salomon.at \
--to=markus.duft@salomon.at \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.