gdb/remote: use scoped_restore to control starting_up flag
authorAndrew Burgess <aburgess@redhat.com>
Mon, 22 Nov 2021 15:16:27 +0000 (15:16 +0000)
committerAndrew Burgess <aburgess@redhat.com>
Wed, 1 Dec 2021 10:07:14 +0000 (10:07 +0000)
commit288712bbaca36bff6578bc839ebcdc3707662f81
tree97dfaed4878cf364043250499b8957c832819c99
parent6976b5b96120ad71af4cec2891f3d8ae7869e4e0
gdb/remote: use scoped_restore to control starting_up flag

This commit makes use of a scoped_restore object to control the
remote_state::starting_up flag within the remote_target::start_remote
method.

Ideally I would have liked to create the scoped_restore inside
start_remote and just leave the restore in place until the end of the
scope, however, I'm worried that doing this would change the behaviour
of GDB.  Specifically, in start_remote, the following code is executed
once the starting_up flag has been restored to its previous value:

  if (breakpoints_should_be_inserted_now ())
    insert_breakpoints ();

I think (but am not 100% sure) that calling install_breakpoints could
end up back inside remote_target::can_download_tracepoint, which does
check the value of remote_state::starting_up.  And so, I'm concerned
that leaving the scoped_restore in place until the end of start_remote
will cause a possible change in behaviour.

To avoid this, and to leave things as close to the current behaviour
as possible, I've split remote_target::start_remote into two, there's
the main function body which moves into remote_target::start_remote_1,
this function uses the scoped_restore to change the ::starting_up
flag, then there's the old remote_target::start_remote, which now just
calls ::start_remote_1, and then does the insert_breakpoints call.

There should be no user visible changes after this commit, unless
there's a situation where the ::starting_up flag could previously have
been left set, if this was the case, then this situation should no
longer be possible.
gdb/remote.c