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

[Michael Snyder <msnyder@vmware.com>]

Pedro Alves wrote:
> 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.

OK, sounds like you've already thought it through then.