Restore the wrongfully deleted empty line.

Address last comments.

Style & comments

Merge the two parts of set child as traced

In D15857#337018, @kib wrote:

In D15857#336986, @yanko.yankulov_gmail.com wrote:

I think John' idea was to move the block which sets the has_ptrace_fork variable to true, down to the code which acts on its true value. De-fact, eliminating the var, and removing one if().

OK, but as far as I can tell we will need p1's PROC_LOCK or the proctree_lock in order to check the PTRACE_FORK flag. Am i missing something obvious again :) ?

We can read it lockless, and re-acquire the proc lock if set to re-read under the lock. This is not much different from reading under the lock, remembering the result, then drop the lock and use the result.

I think John' idea was to move the block which sets the has_ptrace_fork variable to true, down to the code which acts on its true value. De-fact, eliminating the var, and removing one if().

Address 2 of the jhb comments.

bool & yet more style issues

address style issues

Removed the now outdated comment in do_fork

In D15823#335123, @yanko.yankulov_gmail.com wrote:

Just one more question. I can't figure out why we can't reparent the new proc in do_fork instead of waiting for its thread to do it? Any hint will be appreciated.

I am not sure about your question. Can you point to the exact piece of code which you want to move into do_fork ? If you mean proc_reparent() call from fork_return(), I put it there to have all code dealing with the attaching new child to the debugger, in single place. ptracestop() must be called from the stopping thread context, and proc_reparent() as part of the attachment code is naturally located nearby. But I may be mis-interpreting your question, and also I do not see why you are asking.

Yes, that the question. I was trying to figure out why we need the sleep in the fork path at all. Because if we can get rid of the sleep, there is no need to change anything else. So my reasoning was like this - it is either required by the ptrace interface/promises i.e. parent process will not continue execution before the child is attached, or it is part of the implementation of the interface.

I assumed it is not a ptrace requirement because there is no guarantees for the parent/child execution in non-ptraced mode, and went on to see why it might be needed. One thing in the current code is that we can't allow the parent process to exit before the child was reparented as we will not attach to the child.

So my question is if we reparent the child in do_fork wouldn't it be possible and desirable to drop the wait altogether?

Just one more question. I can't figure out why we can't reparent the new proc in do_fork instead of waiting for its thread to do it? Any hint will be appreciated.

I am not sure about your question. Can you point to the exact piece of code which you want to move into do_fork ? If you mean proc_reparent() call from fork_return(), I put it there to have all code dealing with the attaching new child to the debugger, in single place. ptracestop() must be called from the stopping thread context, and proc_reparent() as part of the attachment code is naturally located nearby. But I may be mis-interpreting your question, and also I do not see why you are asking.

In D15823#335057, @kib wrote:

Please generate large diff context when you upload diff into phab, e.g. for svn it would be svn diff -x -U999999, for git diff -U999999.