mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-12-19 01:19:41 +08:00
cbaa41b330
DAP requests have a "defer_stop_events" option that is intended to defer the emission of any "stopped" event until after the current request completes. This was needed to handle async continues like "finish &". However, I noticed that sometimes DAP tests can fail, because a stop event does arrive before the response to the "stepOut" request. I've only noticed this when the machine is fairly loaded -- for instance when I'm regression-testing a series, it may occur in some of the tests mid-series. I believe the problem is that the implementation in the "request" function is incorrect -- the flag is set when "request" is invoked, but instead it must be deferred until the request itself is run. That is, the setting must be captured in one of the wrapper functions. Following up on this, Simon pointed out that introducing a delay before sending a request's response will cause test case failures. That is, there's a race here that is normally hidden. Investigation showed that that deferred requests can't force event deferral. This patch implements this; but more testing showed many more race failures. Some of these are due to how the test suite is written. Anyway, in the end I took the radical approach of deferring all events by default. Most DAP requests are asynchronous by nature, so this seemed ok. The only case I found that really required this is pause.exp, where the test (rightly) expects to see a 'continued' event while performing an inferior function call. I went through all events and all requests and tried to convince myself that this patch will cause acceptable behavior in every case. However, it's hard to be completely sure about this approach. Maybe there are cases that do still need an event before the response, but we just don't have tests for them. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32685 Acked-By: Simon Marchi <simon.marchi@efficios.com>