From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org, Yao Qi <yao@codesourcery.com>
Subject: Re: [PATCH v2] Fix several "set remote foo-packet on/off" commands.
Date: Mon, 28 Apr 2014 19:16:00 -0000 [thread overview]
Message-ID: <20140428191608.GA9089@adacore.com> (raw)
In-Reply-To: <533AB01E.4060003@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]
Hi Pedro,
> gdb/
> 2014-04-01 Pedro Alves <palves@redhat.com>
>
> * remote.c (struct remote_state): Remove multi_process_aware,
[...]
Unfortunately, your patch seems to be introducing a regression,
observable when connecting GDB to QEMU. For instance:
(gdb) set debug remote 1
(gdb) tar rem :4444
Remote debugging using :4444
Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
Packet received: PacketSize=1000;qXfer:features:read+
Packet qSupported (supported-packets) is supported
Sending packet: $Hgp0.0#ad...Ack
Packet received: OK
Sending packet: $qXfer:features:read:target.xml:0,ffb#79...Ack
Packet received: [...]
Sending packet: $qXfer:features:read:arm-core.xml:0,ffb#08...Ack
Packet received: [...]
!!! -> Sending packet: $QNonStop:0#8c...Ack
Packet received:
Remote refused setting all-stop mode with:
What happens, here, it seems, is that GDB thinks it's OK to use
the QNonStop even though it wasn't specified in the qSupported
reply. Looking at the code that sets the feature's status when
not seen in the qSupported reply, we see:
/* Handle the defaults for unmentioned features. */
for (i = 0; i < ARRAY_SIZE (remote_protocol_features); i++)
if (!seen[i])
{
const struct protocol_feature *feature;
feature = &remote_protocol_features[i];
feature->func (feature, feature->default_support, NULL);
}
In the case of PACKET_QNonStop, we have the following definition...
{ "QNonStop", PACKET_DISABLE, remote_supported_packet, PACKET_QNonStop },
... so feature->func is remote_supported_packet, which then sets
the feature as:
static void
remote_supported_packet (const struct protocol_feature *feature,
enum packet_support support,
const char *argument)
{
[warning + return if argument not NULL]
remote_protocol_packets[feature->packet].support = support;
}
However, looking at the packet_support function, it basically
relies on packet_config_support, which itself only looks at
the support field of our feature if "detect" was set to AUTO_BOOLEAN_AUTO:
switch (config->detect)
{
case AUTO_BOOLEAN_TRUE:
return PACKET_ENABLE;
case AUTO_BOOLEAN_FALSE:
return PACKET_DISABLE;
case AUTO_BOOLEAN_AUTO:
return config->support;
default:
gdb_assert_not_reached (_("bad switch"));
}
However, in the case of this option, it's set to AUTO_BOOLEAN_TRUE.
So the config->support value that we set earlier has no effect.
I worked around the issue by making this package a configurable
packet (diff attached) but I have a feeling that there is either
something I am not getting, or perhaps a hole in the current
design. Or perhaps something else? I am not quite clear on what
should be done, yet.
Thanks!
--
Joel
[-- Attachment #2: remote.c.diff --]
[-- Type: text/x-diff, Size: 554 bytes --]
diff --git a/gdb/remote.c b/gdb/remote.c
index dcd3cdd..14dd8c9 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -11878,6 +11878,9 @@ Show the maximum size of the address (in bits) in a memory packet."), NULL,
add_packet_config_cmd (&remote_protocol_packets[PACKET_QPassSignals],
"QPassSignals", "pass-signals", 0);
+ add_packet_config_cmd (&remote_protocol_packets[PACKET_QNonStop],
+ "QNonStop", "non-stop", 0);
+
add_packet_config_cmd (&remote_protocol_packets[PACKET_QProgramSignals],
"QProgramSignals", "program-signals", 0);
next prev parent reply other threads:[~2014-04-28 19:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-31 23:53 [PATCH] " Pedro Alves
2014-04-01 8:55 ` Yao Qi
2014-04-01 12:07 ` Pedro Alves
2014-04-01 12:25 ` [PATCH v2] " Pedro Alves
2014-04-28 19:16 ` Joel Brobecker [this message]
2014-04-29 1:01 ` Pedro Alves
2014-04-29 2:10 ` Hui Zhu
2014-04-29 12:53 ` Joel Brobecker
2014-04-29 13:07 ` Pedro Alves
2014-04-29 14:05 ` Joel Brobecker
2014-04-01 12:48 ` [PATCH] " Yao Qi
2014-04-25 18:04 ` Pedro Alves
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=20140428191608.GA9089@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=yao@codesourcery.com \
/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