A potential problem with target_resume() on multithreaded applications

[Eric PAIRE <e.paire@opengroup.org>]

Could someone explain to me the following problem of gdb on multithreaded
programs in wait_for_inferior() ?

1) When the pid returned by target_wait() is different from the inferior_pid,
	the signal is not SIGTRAP and we don't want to be stopped by the
	signal, then a call to target_resume() is done with an explicit pid
	(infrun.c:725 from gdb-4.17)

2) When the pid is inferior_pid, the signal is not SIGTRAP and we don't
	want to be stopped by the signal, then a call to target_resume()
	is done without an explicit pid (infrun.c:1695 from gdb-4.17)


My problem is that under 1) *ALL* the multithreaded implementations restart
only the explicit thread whereas 2) all threads are restarted. I don't think
that these 2 behaviours are coherent.

My guess is that the 2) is the only valid one, in particular if a signal
handler associated with the signal propagated to the inferior thread
executes a blocking system call, which will be awaken by another thread. This
could lead to a wonderful deadlock, if all the threads are not concurrerntly
running. In that case, all the multithreaded target_resume() should be fixed
to *ONLY* wakeup one thread when the pid is explicit *AND* the step == 1.

Thanks in advance,
-Eric
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Email : e.paire@gr.opengroup.org  | THE Open GROUP - Research Institute
Phone : +33 (0) 476 63 48 71 	  | 2, avenue de Vignate
Fax   : +33 (0) 476 51 05 32	  | F-38610 Gieres      FRANCE