Re: Refuse following the vfork parent if not letting the child run.

[Pedro Alves <pedro@codesourcery.com>]

On Monday 08 June 2009 16:43:28, Daniel Jacobowitz wrote:

> Also, what about MI?

Ah, the MI trick question.  :-)

( The follow-fork-mode model is a bit etchy to begin with.  It
would be simpler if targets supporting forks had to support
multiprocess as well, and we just added new the processes to the
list as we find them.  Then the user just switches to the process
desired before resuming.  But, there's plain gdbserver "target remote", and
we may end up with follow-fork support there.  What do you think
of that?  Anyway, this deadlock still needs to be prevented. )

If the parent is running free, and then vforks, we stop
the inferior.  I'm not sure if this should be considered an
error at the MI level?  As is, MI gets its *stop
notification.  The *why* it stopped ends up being a bit
misterious, though.  I imagine this being a current MI
limitation in other cases too.

 (gdb)
 set detach off
 &"set detach off\n"
 ^done
 (gdb)
 -exec-continue
 ^running
 *running,thread-id="all"
 (gdb)
 &"error resuming execution: can not resume the parent of a vfork in the foreground if not letting the child run until it execs or exits, as it would lock the terminal and hang the  debug session.\n"
 *stopped,frame={addr="0x00007ffff789aee4",func="vfork",args=[],from="/lib/libc.so.6"},thread-id="1",stopped-threads="all"
 (gdb)

If I made that an error call instead I would get this:

 -exec-run
 =thread-exited,id="1",group-id="1828"
 =thread-group-exited,id="1828"
 =library-unloaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2"
 =library-unloaded,id="/lib/libm.so.6",target-name="/lib/libm.so.6",host-name="/lib/libm.so.6"
 =library-unloaded,id="/lib/libc.so.6",target-name="/lib/libc.so.6",host-name="/lib/libc.so.6"
 =thread-group-created,id="1886"
 =thread-created,id="1",group-id="1886"
 ^running
 *running,thread-id="all"
 (gdb)
 =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0"
 =library-loaded,id="/lib/libm.so.6",target-name="/lib/libm.so.6",host-name="/lib/libm.so.6",symbols-loaded="0"
 =library-loaded,id="/lib/libc.so.6",target-name="/lib/libc.so.6",host-name="/lib/libc.so.6",symbols-loaded="0"
 ^error,msg="error resuming execution: can not resume the parent of a vfork in the foreground if not letting the child run until it execs or exits, as it would lock the terminal and  hang the debug session.\n"
 =thread-selected,id="1"
 (gdb)

Meaning, we'd need to do something smarter with exceptions from
within target_follow_fork so to report a *stopped to the frontend
here as well.  (This isn't so much an exceptional case though, in
the sense that it's unexpected --- the caller is prepared to
handle this "refuse to go" case.)

(insert rant about one of ^running or ^error looking out of
place -- take your pick)

So, I don't know what's best here.  MI with multiforks is
basically undefined at this point.

-- 
Pedro Alves