[ptrace] please review follow fork/exec changes

Dmitry Mikulin dmitrym at juniper.net
Thu Feb 9 20:50:51 UTC 2012


> The semantic of PL_FLAG_EXEC up until now is very simple: it indicates
> that current stop occured during the first return to usermode after
> successful exec. The proposed patch breaks the semantic, because now
> some stops which satisfy the stated condition are no longer marked with
> the flag.
>
> That said, I am lost. You stated that you still need some stops at
> exec even when not PT_FOLLOW_EXEC is requested. Why usermode cannot
> remember whether the PT_FOLLOW_EXEC was set for the process, and ignore
> PL_FLAG_EXEC if not requested ?

I was trying to avoid making ugly changes in gdb if it was possible not to make ugly changes in the kernel. I changed gdb to work without PT_FOLLOW_EXEC.

> I just gave up and added PL_FLAG_EXECF, which is set when PT_FOLLOW_EXEC
> was set and exec is active. Would this work for your purposes ?
> PL_FLAG_EXECF has the same semantic as PL_FLAG_EXEC had in your
> follow-exec.patch. But the stop set is not changed comparing with the
> stock src.
>
> Are you fine with PL_FLAG_CHILD part of the changes ? If yes, I will
> commit it to make some progress.

yes, the PL_FLAG_CHILD part works for me.
Please commit it and we can move on to the next part of the review.





More information about the freebsd-current mailing list