This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Time to attend to a lin-lwp.c FIXME (or two)?



Mark,

In lin-lwp.c, we find the following note from you:

      if (signal_stop_state (signo) == 0
	  && signal_print_state (signo) == 0
	  && signal_pass_state (signo) == 1)
	{
	  /* FIMXE: kettenis/2001-06-06: Should we resume all threads
             here?  It is not clear we should.  GDB may not expect
             other threads to run.  On the other hand, not resuming
             newly attached threads may cause an unwanted delay in
             getting them running.  */
	  child_resume (pid_to_ptid (GET_LWP (lp->ptid)), lp->step, signo);
	  lp->stopped = 0;
	  status = 0;
	  goto retry;
	}

Well, I think I've found a situation where we SHOULD resume all
threads (or address another FIXME in the same file, see below), so I
thought I'd ask if you've given this any more thought.

The situation is that a certain Ada program at one point has 4 threads
running (3 + a pthread manager).  A break point is set on an
instruction that is to be executed by one of the threads (call it
thread 4).  At the same time, another thread (call it thread 1) is
suspended, waiting for a restart signal (SIG32, which GDB sets to
nostop, noprint, pass).  The program is nondeterministic, but it can
happen that the breakpoint is reached on thread 4 while there is a
restart signal pending on thread 1.

Suppose at this point, we execute

   delete
   thread 1
   cont

This particular sequence of actions on the user's part eventually gets
us to the code above.  This resumes thread 1, which simply handles the
signal and goes back to sleep.  The other threads are also stopped
(the effect of switching to thread 1 and then continuing is that
lin_lwp_resume sees a non-zero on this thread and aborts the
resumption).  Therefore, we hang at this point.  

Hmm... perhaps it's this other FIXME in lin_lwp_resume that needs
fixing?  This particular signal is not supposed to stop the process
(pass, noprint, nostop, as indicated above) so perhaps the proper
handling of

      /* If we have a pending wait status for this thread, there is no
         point in resuming the process.  */
      if (lp->status)
	{
	  /* FIXME: What should we do if we are supposed to continue
             this thread with a signal?  */
	  gdb_assert (signo == TARGET_SIGNAL_0);
	  return;
	}

is instead to return here only if the signal is supposed to stop GDB (or
print), and otherwise to set signo to the indicated signal and carry on?

What do you think?  In the meantime, I am going to prepare a patch along the
lines of the last paragraph.

Paul Hilfinger


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]