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.

0 files changed, 0 insertions, 0 deletions