From: Jan Kiszka <jan.kiszka@web.de>
To: qemu-devel@nongnu.org
Cc: Andreas Schultz <aschultz@warp10.net>,
Paul Brook <paul@codesourcery.com>,
kvm@vger.kernel.org
Subject: [Qemu-devel] Re: gdbstub: packet reply is too long
Date: Mon, 29 Dec 2008 15:58:47 +0100 [thread overview]
Message-ID: <4958E5A7.4000303@web.de> (raw)
In-Reply-To: <20081226233012.GA9221@caradoc.them.org>
[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]
Daniel Jacobowitz wrote:
> On Sun, Dec 21, 2008 at 12:44:04AM +0100, Jan Kiszka wrote:
>> And that means setting current_gdbarch while keeping target_gdbarch -
>> that's where reality (existing gdb code) bites us. Again, I'm not
>> arguing against fixing this, I'm arguing in keeping qemu's workaround
>> until this is done. I will look into the gdb part, but one after the other.
>
> No, it does not mean setting current_gdbarch different from
> target_gdbarch. With the current gdbarch set to a 64-bit one that
> accurately describes the target, GDB should be able to debug code
> running in 32-bit mode. If it can't, there are simply bugs in GDB to
> fix.
Well, in the current gdb design, current_gdbarch is consulted when
disassembling the code while target_gdbarch defines the register set
that is exchanged with the remote stub.
>
> If you'd like to reach some solution to this problem, which I've seen
> come up on the QEMU list a half-dozen times now, please describe how
> you're using GDB on the gdb@sourceware.org mailing list and let's see
> if we can't fix the GDB bugs. I'm pretty sure that any solution is
> going to involve always transferring the x86-64 register set, though.
I'm pretty sure that the final solution will involve extended x86
register sets in order to inform the frontend about the full target CPU
state so that it can set the right current_gdbarch automatically. That's
one reason (the other is current/target_gdbarch decoupling) why I see no
quick "bug fix" on the gdb side to actually solve the issue and suggest
the reintroduction of the qemu workaround until gdb is enhanced
appropriately.
But you I right, it's time to start a discussion on the gdb list,
hopefully laying the ground for a better x86 low-level support. And
Maybe I actually miss some smart intermediate step towards this.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2008-12-29 15:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1229776952.22890.2.camel@ws-aschultz>
2008-12-20 15:49 ` [Qemu-devel] Re: gdbstub: packet reply is too long Jan Kiszka
2008-12-20 20:35 ` Paul Brook
2008-12-20 21:00 ` Jan Kiszka
2008-12-20 21:03 ` Paul Brook
2008-12-20 21:22 ` Jan Kiszka
2008-12-20 21:34 ` Paul Brook
2008-12-20 21:55 ` Jan Kiszka
2008-12-20 22:08 ` Paul Brook
2008-12-20 22:34 ` Jan Kiszka
2008-12-20 22:46 ` Paul Brook
2008-12-20 23:44 ` Jan Kiszka
2008-12-26 23:30 ` Daniel Jacobowitz
2008-12-29 14:58 ` Jan Kiszka [this message]
2008-12-30 22:43 ` Daniel Jacobowitz
2009-01-02 12:53 ` Jan Kiszka
2009-01-03 1:53 ` Jamie Lokier
2009-01-04 13:50 ` Jan Kiszka
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=4958E5A7.4000303@web.de \
--to=jan.kiszka@web.de \
--cc=aschultz@warp10.net \
--cc=kvm@vger.kernel.org \
--cc=paul@codesourcery.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).