[RFC]: Ugly thread step situation

[jjohnstn <jjohnstn at redhat dot com>]

I recently tracked down a problem with gdb on RHEL3 Linux regarding 
stepping threads.  What happens is that in some instances, lin-lwp.c is 
asked to step the thread of interest.  We then wait on all threads.  Due 
to some form of race condition, the wait does not get back the trap from 
the stepped thread.  If we have a number of waiting events (e.g. thread 
create events, other breakpoints), lin-lwp picks one of them.

Now it gets interesting.  Infrun.c thinks the current thread is being 
stepped and isn't ready for a breakpoint coming back.  On x86, it makes a 
miscalculation of the pc value (for a breakpoint it should back up 1, for 
a step it doesn't have to).  We end up pointing at an invalid pc (we 
didn't back up 1) and everything falls apart from there.

To fix this quickly, I added the accompanying patch to lin-lwp.c.  What it 
does is ensure that we wait on any currently stepping lwp.  In truth, this 
isn't as bad as it sounds.  The lin-lwp code later on is set up to pick 
the stepping lwp over all other events.  This just keeps the scenario 
above from occurring.

Obviously, this doesn't solve everything.  Perhaps the decrement of the pc 
needs to be done once we have established whether the thread has changed 
underneath us.  We also could use a hook to run the lwp list and find out 
if the current lwp was stepping or encountered a breakpoint.

Anyway, if the consensus is that the patch is helpful in the short-term, I 
am more than happy to check it in.

-- Jeff J.

2004-09-14  Jeff Johnston  <jjohnstn@redhat.com>

	* lin-lwp.c (find_singlestep_lwp_callback): New static function.
	(lin_lwp_wait): Change code to specifically wait on any LWP
	that is currently stepping.

Attachment: lin-lwp.patch
Description: Text document