aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2loc.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2014-04-29 14:01:27 +0100
committerPedro Alves <palves@redhat.com>2014-04-29 14:01:27 +0100
commitca4f7f8bebc069b8beec58754dc721e9be0798c7 (patch)
treeeb0f68755cd593dc62a139bd42b38be2d4521651 /gdb/dwarf2loc.c
parent11903c4c65d3bf0391362ac389b96ffdd9f58212 (diff)
downloadbinutils-ca4f7f8bebc069b8beec58754dc721e9be0798c7.zip
binutils-ca4f7f8bebc069b8beec58754dc721e9be0798c7.tar.gz
binutils-ca4f7f8bebc069b8beec58754dc721e9be0798c7.tar.bz2
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.
Diffstat (limited to 'gdb/dwarf2loc.c')
0 files changed, 0 insertions, 0 deletions