darkkirb/old-cross-binutils
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

GDBserver: clean up 'cont_thread' handling

Browse source 
As no place in the backends check cont_thread anymore, we can stop
setting and clearing it in places that resume the target and wait for
events.  Instead simply clear it whenever a new GDB connects.

gdb/gdbserver/
2014-11-12  Pedro Alves  <palves@redhat.com>

	* server.c (cont_thread): Update comment.
	(start_inferior, attach_inferior): No longer clear cont_thread.
	(handle_v_cont): No longer set cont_thread.
	(captured_main): Clear cont_thread each time a GDB connects.
This commit is contained in:
Pedro Alves 2014-11-12 11:17:40 +00:00
parent c2c118cfe1
commit 40e91bc71f
2 changed files with 9 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
gdb/gdbserver/ChangeLog
View file

@ -1,3 +1,10 @@
2014-11-12 Pedro Alves <palves@redhat.com>
* server.c (cont_thread): Update comment.
(start_inferior, attach_inferior): No longer clear cont_thread.
(handle_v_cont): No longer set cont_thread.
(captured_main): Clear cont_thread each time a GDB connects.
2014-11-12 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_wait_1): Don't force a wait for the Hc

26
gdb/gdbserver/server.c
View file

@ -41,11 +41,7 @@
requirement, so `Hc pPID.TID' is pretty much undefined. So
CONT_THREAD can be null_ptid for no `Hc' thread, minus_one_ptid for
resuming all threads of the process (again, `Hc' isn't used for
multi-process), or a specific thread ptid_t.
We also set this when handling a single-thread `vCont' resume, as
some places in the backends check it to know when (and for which
thread) single-thread scheduler-locking is in effect. */
multi-process), or a specific thread ptid_t. */
ptid_t cont_thread;
/* The thread set with an `Hg' packet. */
@ -225,10 +221,6 @@ start_inferior (char **argv)
signal (SIGTTIN, SIG_DFL);
#endif
/* Clear this so the backend doesn't get confused, thinking
CONT_THREAD died, and it needs to resume all threads. */
cont_thread = null_ptid;
signal_pid = create_inferior (new_argv[0], new_argv);
/* FIXME: we don't actually know at this point that the create
@ -307,10 +299,6 @@ attach_inferior (int pid)
whichever we were told to attach to. */
signal_pid = pid;
/* Clear this so the backend doesn't get confused, thinking
CONT_THREAD died, and it needs to resume all threads. */
cont_thread = null_ptid;
if (!non_stop)
{
last_ptid = mywait (pid_to_ptid (pid), &last_status, 0, 0);
@ -2305,17 +2293,6 @@ handle_v_cont (char *own_buf)
if (i < n)
resume_info[i] = default_action;
/* `cont_thread' is still used in occasional places in the backend,
to implement single-thread scheduler-locking. Doesn't make sense
to set it if we see a stop request, or a wildcard action (one
with '-1' (all threads), or 'pPID.-1' (all threads of PID)). */
if (n == 1
&& !(ptid_equal (resume_info[0].thread, minus_one_ptid)
|| ptid_get_lwp (resume_info[0].thread) == -1)
&& resume_info[0].kind != resume_stop)
cont_thread = resume_info[0].thread;
else
cont_thread = minus_one_ptid;
set_desired_thread (0);
resume (resume_info, n);
@ -3267,6 +3244,7 @@ captured_main (int argc, char *argv[])
multi_process = 0;
/* Be sure we're out of tfind mode. */
current_traceframe = -1;
cont_thread = null_ptid;
remote_open (port);