[patchv3] Workaround gdbserver<7.7 for setfs
Commit Message
On Wed, 30 Mar 2016 16:17:11 +0200, Pedro Alves wrote:
> E.g., reading this I'm left wondering, did it always respond OK to
> unknown vFile packets, or to all unknown packets? I think it was
> actually the latter.
To all vFile packets. Other packets produce on gdbserver-7.6:
Sending packet: $MustReplyEmpty#c4...Ack
Packet received: E01
Is the patch OK for check-in this way?
Thanks,
Jan
gdb/gdbserver/ChangeLog
2016-04-04 Jan Kratochvil <jan.kratochvil@redhat.com>
* remote.c (unknown_vfile_replies_ok): New variable.
(packet_config_support): Read it.
(remote_start_remote): Set it.
Comments
On 04/04/2016 10:14 PM, Jan Kratochvil wrote:
> On Wed, 30 Mar 2016 16:17:11 +0200, Pedro Alves wrote:
>> E.g., reading this I'm left wondering, did it always respond OK to
>> unknown vFile packets, or to all unknown packets? I think it was
>> actually the latter.
>
> To all vFile packets. Other packets produce on gdbserver-7.6:
> Sending packet: $MustReplyEmpty#c4...Ack
> Packet received: E01
MustReplyEmpty is actually not a useful probe packet, because
that's actually an M (write memory) packet, which is then
misinterpreted and fails the write. So not an unknown packet.
Try qMustReplyEmpty or something like that instead.
Thanks,
Pedro Alves
@@ -1496,6 +1496,15 @@ enum {
static struct packet_config remote_protocol_packets[PACKET_MAX];
+/* gdbserver < 7.7 (before its fix from 2013-12-11) did reply to any
+ unknown vFile packet with string "OK". "OK" gets interpreted by GDB
+ as a reply to known packet. For packet "vFile:setfs:" it is an
+ invalid reply and GDB would return error in
+ remote_hostio_set_filesystem, making remote files access impossible.
+ If this variable is non-zero it means the remote gdbserver is buggy
+ and any not yet detected packets are assumed as unsupported. */
+static int unknown_vfile_replies_ok;
+
/* Returns the packet's corresponding "set remote foo-packet" command
state. See struct packet_config for more details. */
@@ -1519,6 +1528,9 @@ packet_config_support (struct packet_config *config)
case AUTO_BOOLEAN_FALSE:
return PACKET_DISABLE;
case AUTO_BOOLEAN_AUTO:
+ if (unknown_vfile_replies_ok && config->name != NULL
+ && startswith (config->name, "vFile:"))
+ return PACKET_DISABLE;
return config->support;
default:
gdb_assert_not_reached (_("bad switch"));
@@ -4023,6 +4035,21 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p)
if (packet_support (PACKET_QAllow) != PACKET_DISABLE)
remote_set_permissions (target);
+ /* See unknown_vfile_replies_ok description. */
+ {
+ const char vfile_mustreplyempty[] = "vFile:MustReplyEmpty:";
+
+ putpkt (vfile_mustreplyempty);
+ getpkt (&rs->buf, &rs->buf_size, 0);
+ if (strcmp (rs->buf, "OK") == 0)
+ unknown_vfile_replies_ok = 1;
+ else if (strcmp (rs->buf, "") == 0)
+ unknown_vfile_replies_ok = 0;
+ else
+ error (_("Remote replied unexpectedly to '%s': %s"), vfile_mustreplyempty,
+ rs->buf);
+ }
+
/* Next, we possibly activate noack mode.
If the QStartNoAckMode packet configuration is set to AUTO,