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

Michael Snyder
2008-12-01T22:38:04Z

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.