Searched hist:12019 (Results 1 - 2 of 2) sorted by relevance
| /gem5/src/base/ | ||
| H A D | remote_gdb.hh | 12019:65939e37768a Wed May 10 02:18:00 EDT 2017 Gabe Black <gabeblack@google.com> 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> |
| H A D | remote_gdb.cc | 12019:65939e37768a Wed May 10 02:18:00 EDT 2017 Gabe Black <gabeblack@google.com> 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> |
Completed in 15 milliseconds