From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17332 invoked by alias); 8 Jun 2009 17:44:17 -0000 Received: (qmail 17321 invoked by uid 22791); 8 Jun 2009 17:44:16 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Jun 2009 17:44:10 +0000 Received: (qmail 19521 invoked from network); 8 Jun 2009 17:44:08 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Jun 2009 17:44:08 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: Refuse following the vfork parent if not letting the child run. Date: Mon, 08 Jun 2009 17:44:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <200906081431.38913.pedro@codesourcery.com> <200906081604.35800.pedro@codesourcery.com> <20090608154328.GA21076@caradoc.them.org> In-Reply-To: <20090608154328.GA21076@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906081845.12772.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00188.txt.bz2 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