[ptrace] please review follow fork/exec changes

[Dmitry Mikulin]

>> Gdb needs to be able to read/write process memory between the time the
>> child is forked and exec is called (in the vfork case). Without the change
>> it causes a kernel panic when gdb tries to read/write process memory. Since
>> my understanding of the kernel is a bit limited, it was the best I could do
>> at the time. I will send more details about the panic once I get a working
>> fbsd system again. Maybe there's a better way to deal with the panic.
> Please provide more details, I am looking forward for the panic
> message and backtrace.

As soon as I get my FreeBSD box fixed, hopefully tomorrow.


>
>>> Lets postpone discussion of the orphan.patch for later.
>> OK.
>>
>>> The follow-fork.patch and follow-exec.patch make me wonder, and I
>>> already expressed my doubts. IMO, all features, except one bug, are
>>> already presented in the stock src.
>>>
>>> More, suggested follow-{fork,exec} patches break the SCE/SCX tracers
>>> notification of fork and exec events, since TDB_FORK and TBD_EXEC flags
>>> are consumed before syscall returns (I also said this previously).
>>
>>
>>
>>> Namely, if the process is being debugged, the successfull [f]execve()
>>> causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary.
>>>
>>> Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not
>>> revealed by my testing during the development, because I only tested
>>> SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next
>>> stop is not SCX, then follow-fork notification is not sent. After this
>>> nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation.
>>> Child is put into stop state as needed to not loose it.
>> I think this will fix only a part of the problem, the one that relates to
>> PT_CONTINUE.
>>
>> I still need the change that forces a stop in both child and parent on
>> fork(). Without my changes the notification is generated in the child but
>> not in the parent. I need to be able to have both processes stopped in gdb
>> in order to clean up and detach from the parent, and initialize and attach
>> to the child. The main reason I need both processes stopped is that gdb has
>> to be able to read/write into both processes address space and registers.
>> Ideally I would like to have a single event generated for fork() at a point
>> where both child and parent are stopped and available for ptrace read/write
>> requests.  Do you think it's possible?
> The lack of the notification for parent is exactly what the patch I
> posted fixes. More exactly, it is the lack of notification for parent
> with PT_CONTINUE loop. I will commit this today.
>
> Regarding a single notification. Currently, parent arrives at the
> syscall return code only after the child is attached to the debugger.
> See the cv_wait() in kern_fork.c:739. In other words, if you get the
> PL_FLAG_FORK, the child is already attached (at last it shall be). My
> scescx.c code illustrates this well, IMO.

OK, I see. I need to verify that it works with gdb and possibly tweak it to match the kernel.

>
> You still get a separate stop from the child, but I do not see how is it
> harmful.

It's not harmful as long as gdb can tell that those stops are generated by the fork().