Thanks for taking a look at it. I'll try to explain the changes the best I can:
the work was done nearly 6 months ago...
I would certainly appreciate some more words describing the changes.
What is the goal of introducing the PT_FOLLOW_EXEC ? To not force
the debugger to filter all syscall
On 01/26/2012 04:23 AM, Kostik Belousov wrote:
On Wed, Jan 25, 2012 at 03:48:04PM -0800, Dmitry Mikulin wrote:
Thanks for taking a look at it. I'll try to explain the changes the best I
can: the work was done nearly 6 months ago...
I would certainly appreciate some more words describing
Attached are 4 separate patches for each somewhat independent portion of the
kernel work related to the follow-fork implementation.
On 01/26/2012 04:23 AM, Kostik Belousov wrote:
On Wed, Jan 25, 2012 at 03:48:04PM -0800, Dmitry Mikulin wrote:
Thanks for taking a look at it. I'll try
On 01/28/2012 11:48 PM, Kostik Belousov wrote:
On Fri, Jan 27, 2012 at 10:12:13AM -0800, Dmitry Mikulin wrote:
Attached are 4 separate patches for each somewhat independent portion of
the kernel work related to the follow-fork implementation.
Ok, as I said, I think that vfork-fork.patch
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
Please provide more details, I am looking forward for the panic
message and backtrace.
I can't seem to get the panic with the latest source base, but tracing doesn't
appear to work with vfork(). I attached a modified test case to closer model
what gdb is doing. If you change fork() to
I see what is going on. The wait loop for P_PPWAIT in do_fork() simply
do not allow the ptracestop() in the syscall return path to be reached.
There seems to be more problems. In particular, I do not see anything
which would prevent the child from being reapped while the loop is
executing
;
+else
+p-p_flag = ~P_FOLLOWEXEC;
+break;
The SIGHUP I mentioned is due to the fact that the parent exits immediately. I
guess that's not a particularly well written program.
On 02/06/2012 01:19 PM, Dmitry Mikulin wrote:
I see what is going on. The wait loop for P_PPWAIT
So, do you in fact need to distinguish exec stops from syscall exit
against exec stops from PT_FOLLOW_EXEC,
This is pretty much what I need. It's the same stop in syscall return right? I
don't want to change when the stop happens, I want to have an lwpinfo flag that
tells me when a stop
Well, that didn't work... Not sure why since it broke existing gdb. My guess is
we're not getting the exec stops we used to get. Might have to wait till
tomorrow to get more details.
On 02/07/2012 12:45 PM, Dmitry Mikulin wrote:
So, do you in fact need to distinguish exec stops from
The patch I sent earlier works for me. Just wanted to let you know to
illustrate what I would like to see from the kernel.
I'm trying to see if there's way not to add flags with semantics similar to
TDB_EXEC. I think the problem with TDB_EXEC is that is serves a trigger for a
stop as well as
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
On 02/09/2012 04:17 PM, Konstantin Belousov wrote:
On Thu, Feb 09, 2012 at 12:48:26PM -0800, Dmitry Mikulin wrote:
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
On 02/13/2012 07:28 AM, Konstantin Belousov wrote:
I looked at the orphan.patch.
Am I right that the orphans are the real childs of the process which
are temporarily reparented to the debugger ? Whatever they are, a comment
should be added to proc.h describing what does it mean.
Done.
The problem I'm trying to solve is to allow a parent to collect it's child
exit status while we're following its child. Gdb detaches from the parent
upon successful switch-over from parent to child. At this point due to
re-parenting the parent loses the child to gdb and if it's in a wait()
On 02/15/2012 08:32 AM, Konstantin Belousov wrote:
On Mon, Feb 13, 2012 at 02:50:45PM -0800, Dmitry Mikulin wrote:
It seems that now wait4(2) can be called from the real (non-debugger)
parent first and result in the call to proc_reap(), isn't it ? We would
then just reparent the child back
On 02/15/2012 09:40 AM, Konstantin Belousov wrote:
On Wed, Feb 15, 2012 at 09:22:10AM -0800, Dmitry Mikulin wrote:
On 02/15/2012 08:32 AM, Konstantin Belousov wrote:
On Mon, Feb 13, 2012 at 02:50:45PM -0800, Dmitry Mikulin wrote:
It seems that now wait4(2) can be called from the real (non
I'm not sure we are on the same page. Let's do it from the very beginning.
The real parent calls wait4() and enters kern_wait() while the child is in a
zombie state. The child is in the gdb's children list and the real parent's
orphan list.
We enter proc_reap() because the child is caught by
18 matches
Mail list logo
