Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 01 December 2008 18:58:31, Michael Snyder wrote:

> I'm not sure if this change goes far enough.

This patch restored the same behaviour to what happened
when GDB still used context-switching.  No more, no less.
When you had context-switching, no matter which side of
the fork you followed, the current infrun context would have
been left to the thread that ended up being set as current.
Without it, you have to refetch a new pointer to the current
thread, as it may be a different thread that it was on entry.

> If a multi-threaded program forks, only the currently
> executing thread survives in the child.  
> All others are 
> left behind (and its not unlikely that the thread library
> is left in an inconsistant state, possibly leading to
> deadlocks).

You mean 'not unlikely' in thread library implementations
in several targets, or 'not unlikely' in current glibc/ntpl
implementations?  glibc is supposed to handle that gracefully.

> 
> We can't do anything about that, but we could, eg.,
> invalidate all known debugger state having to do with
> other threads.  Clear the gdb thread list and preserve
> only the current thread.

The new fork *is* considered a new inferior, and starts
with only one thread listed.  In mainline,
linux_nat_switch_fork always clears the thread list
and adds a new thread.  In a true multi-process linux 
native implementation (which can leave GDB attached to
both parent and child, and have them running
simultaneously (*)), we'd still want to consider the child
fork a new single-threaded inferior, and defer to
thread_db to find the thread's thread_db id (and eventually, any
other thread, in the child in case that changes in the future).
Other targets may behave differently, so this is target
side concern.

(*) - I'm working some on that.

-- 
Pedro Alves