From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: <gdb@sourceware.org>
Subject: GDB/remote: RSP `g' packet size, advice sought
Date: Thu, 24 May 2012 19:17:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.10.1205241953030.11227@tp.orcam.me.uk> (raw)
Hi,
I've been struggling with a problem with the RSP `g' packet size, that
once initialised may only be further shrunk, and never expanded back.
The issue can be easily reproduced with the MIPS target using QEMU, e.g.:
(gdb) target remote | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kc --semihosting --monitor null --serial null -kernel /dev/null
Remote debugging using | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kc --semihosting --monitor null --serial null -kernel /dev/null
0x00100000 in ?? ()
(gdb) target remote | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kf --semihosting --monitor null --serial null -kernel /dev/null
A program is being debugged already. Kill it? (y or n) y
QEMU: Terminated via GDBstub
Remote debugging using | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kf --semihosting --monitor null --serial null -kernel /dev/null
Remote 'g' packet reply is too long:
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000400000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000073930000000000
(gdb)
This is because the 24Kc does not support the FPU and the 24Kf does, and
hence the latter produces a longer `g' reply packet that includes the
extra FPU state. However the remote backend has already shrunk its `g'
packet buffer size when talking to the 24Kc and cannot expand it back.
The only way to recover is to restart GDB from scratch that can be
annoying.
I have tracked down the cause to be the way the remote backend
initialises the `g' packet size. It's only done in init_remote_state that
is called once, when gdbarch data is initialized. The initial size is
calculated based on the maximum number of registers supported by the
architecture:
rsa->regs = GDBARCH_OBSTACK_CALLOC (gdbarch,
gdbarch_num_regs (gdbarch),
struct packet_reg);
rsa->sizeof_g_packet = map_regcache_remote_table (gdbarch, rsa->regs);
Then this is further adjusted whenever a `g' packet reply is received in
process_g_packet:
if (buf_len > 2 * rsa->sizeof_g_packet)
error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
[...]
if (buf_len < 2 * rsa->sizeof_g_packet)
{
rsa->sizeof_g_packet = buf_len / 2;
[...]
-- which is as quoted the place the error message comes from.
This certainly has to be fixed, but the question is why we only ever
initialise sizeof_g_packet once? I agree we should shrink it according to
the particular remote stub's needs as we need to get the size of the
corresponding `G' packet right. However it looks to me like we should
really reset sizeof_g_packet back to the initial size whenever a remote
connection is terminated. Or it should really be enough to do this in
remote_open_1.
Is there any particular reason why we're not doing this? It seems so
obvious and the assumption that any subsequent remote connections will
only produce smaller `g' packets or at worst ones of the same size seems a
little bit odd to me?
It looks to me like remote_open_1 should simply call init_remote_state
directly and then remote_close call a complement that we don't have yet
that would free up structures allocated in init_remote_state. Does my
understanding seem reasonable?
Thanks for any feedback.
Maciej
next reply other threads:[~2012-05-24 19:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 19:17 Maciej W. Rozycki [this message]
2012-06-05 14:27 ` Daniel Jacobowitz
2012-06-07 19:18 ` Maciej W. Rozycki
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=alpine.DEB.1.10.1205241953030.11227@tp.orcam.me.uk \
--to=macro@codesourcery.com \
--cc=gdb@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).