Fix remote connection to targets that don't support the QNonStop packet.
authorPedro Alves <palves@redhat.com>
Tue, 29 Apr 2014 13:01:27 +0000 (14:01 +0100)
committerPedro Alves <palves@redhat.com>
Tue, 29 Apr 2014 13:01:27 +0000 (14:01 +0100)
commitca4f7f8bebc069b8beec58754dc721e9be0798c7
treeeb0f68755cd593dc62a139bd42b38be2d4521651
parent11903c4c65d3bf0391362ac389b96ffdd9f58212
Fix remote connection to targets that don't support the QNonStop packet.

... and others.  The recent patch that fixed several "set remote
foo-packet on/off" commands introduced 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:

The "QNonStop" feature is associated with the PACKET_QNonStop packet,
with a default of PACKET_DISABLE, so GDB should not be sending the
packet at all.

The patch that introduced the regression decoupled packet_config's
'detect' and 'support' fields, making the former (an auto_boolean)
purely the associated "set remote foo-packet" command's variable.  In
the example above, the packet config's 'supported' field does end up
correctly set to PACKET_DISABLE.  However, nothing is presently
initializing packet configs that don't actually have a command
associated.  Those configs's 'detect' field then ends up set to
AUTO_BOOLEAN_TRUE, simply because that happens to be 0.  This forces
GDB to assume the packet is supported, irrespective of what the target
claims it supports, just like if the user had done "set remote
foo-packet on" (this being the associated command, if there was one).

Ideally, all packet configs would have a command associated.  While
that isn't true, make sure all packet configs are initialized, even if
no command is associated, and add an assertion that prevents adding
more packets/features without an associated command.

Tested on x86_64 Fedora 17, against pristine gdbserver, and against a
gdbserver with the QNonStop packet/feature disabled with a local hack.

gdb/
2014-04-29  Pedro Alves  <palves@redhat.com>

* remote.c (struct packet_config) <detect>: Extend comment.
(add_packet_config_cmd): Don't set the config's detect or support
fields here.
(init_all_packet_configs): Also initialize the config's 'detect'
field.
(reset_all_packet_configs_support): New function.
(remote_open_1): Call reset_all_packet_configs_support instead of
init_all_packet_configs.
(_initialize_remote): Initialize all packet configs.  Assert that
all packets have an associated command, except a few known
outliers.
gdb/ChangeLog
gdb/remote.c