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 t
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-d
On Wed, Feb 15, 2012 at 09:54:44AM -0800, Dmitry Mikulin wrote:
>
>
> 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, Dm
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 to
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-debugger)
> >parent first and result i
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 to the caller, still leaving the
> >>>zombie
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()
it'll
On Mon, Feb 13, 2012 at 02:04:24PM -0800, Dmitry Mikulin wrote:
>
>
> 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,
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.
Pl
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.
Please provide me with a test case that demonstrates the issue
solve
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 brea
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 breaks the semantic, because now
> >some stops w
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 Wed, Feb 08, 2012 at 04:51:57PM -0800, Dmitry Mikulin wrote:
> 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 p
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 a
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 syscal
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 occ
On Monday, February 06, 2012 10:12:11 pm David Xu wrote:
> On 2012/1/26 7:48, Dmitry Mikulin wrote:
> >
>
> > The debugger needs to intercept fork() in both parent and child so it
> > can detach from the old process and attach to the new one. Maybe it'll
> > make more sense in the context of gd
On Mon, Feb 06, 2012 at 01:19:30PM -0800, Dmitry Mikulin wrote:
>
> >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 w
On 2012/1/26 7:48, Dmitry Mikulin wrote:
The debugger needs to intercept fork() in both parent and child so it
can detach from the old process and attach to the new one. Maybe it'll
make more sense in the context of gdb changes. Should I send them too?
Don't think Marcel included that patch
Oops, this should be the part of the patch that sets the flag:
@@ -873,6 +872,12 @@ kern_ptrace(struct thread *td, int req, pid_t pid,
else
p->p_flag &= ~P_FOLLOWFORK;
break;
+case PT_FOLLOW_EXEC:
+if (data)
+p->p_flag |= P_FOLLOWEXEC;
+
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 (assum
On Fri, Feb 03, 2012 at 04:01:46PM -0800, Dmitry Mikulin wrote:
>
> >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 t
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 vfork(
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
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 is j
On Mon, Jan 30, 2012 at 10:26:25AM -0800, Dmitry Mikulin wrote:
>
>
> 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
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 is just wrong.
Lets postpone discussion of the orpha
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 to expla
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 the
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 the changes.
> >
> >What is the goal of introdu
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 exi
On Tue, Jan 24, 2012 at 01:36:55PM -0800, Marcel Moolenaar wrote:
> All,
>
> Please review the attached changes (done by Dmitry -- CC'd) to add support for
> PT_FOLLOW_EXEC and cleanup PT_FOLLOW_FORK.
>
> I'll commit this when there are no comments/objections.
> Thanks,
I would certainly appreci
33 matches
Mail list logo
