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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
