> 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.Received on Thu Feb 09 2012 - 19:50:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:23 UTC