misc: Make the remote GDB stub more resilient to bad connections.
authorGabe Black <gabeblack@google.com>
Wed, 10 May 2017 06:18:48 +0000 (23:18 -0700)
committerGabe Black <gabeblack@google.com>
Fri, 12 May 2017 09:43:14 +0000 (09:43 +0000)
commit7c94dc236389a9c3bbb656e2666496c060e38334
treee9a50d5bd3273ace7660efcc39230c726afc76ac
parent6b1069c4073ba51bdd18a716955ee37915ef89dd
misc: Make the remote GDB stub more resilient to bad connections.

Currently, if the remote gdb stub fails to read a byte from an incoming
packet because the connection has been dropped, the read call will return
anyway and the calling code will have no way to know something bad
happened. It might reattempt the read over and over again waiting for some
particular byte, doomed to never make forward progress.

This change modifies the remote GDB code so that if a read or write call
fails, it will instead detach from the debugger and continue. Before this
change, When simulating a port scan, ie connecting to the debugger port
and then immediately dropping the connection using this command:

nc -v -n -z -w 1 127.0.0.1 7000

gem5 would enter the previously described death spiral. After it, gem5
detaches from the bad connection and resumes execution. Subsequently
attaching with gdb was successful.

This code is written in a C centric style, and would benefit from some
refactoring.

Change-Id: Ie3c0bb35b9cfe3671d0f731e3907548bae0d292f
Reviewed-on: https://gem5-review.googlesource.com/3180
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
src/base/remote_gdb.cc
src/base/remote_gdb.hh