From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21454 invoked by alias); 1 May 2009 16:54:23 -0000 Received: (qmail 21445 invoked by uid 22791); 1 May 2009 16:54:22 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,SARE_SUB_GETRID,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout2.012.net.il (HELO mtaout2.012.net.il) (84.95.2.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 May 2009 16:54:15 +0000 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KIZ00A0056U3D00@i_mtaout2.012.net.il> for gdb-patches@sourceware.org; Fri, 01 May 2009 19:54:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.230.216]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KIZ00DIB5M9BC90@i_mtaout2.012.net.il>; Fri, 01 May 2009 19:54:10 +0300 (IDT) Date: Fri, 01 May 2009 16:54:00 -0000 From: Eli Zaretskii Subject: Re: Can we get rid of go32_stop? (and its normal_stop call?) In-reply-to: <200905011724.36973.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83r5z8darm.fsf@gnu.org> References: <200905011514.27632.pedro@codesourcery.com> <83vdokddvk.fsf@gnu.org> <200905011724.36973.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-05/txt/msg00028.txt.bz2 > From: Pedro Alves > Date: Fri, 1 May 2009 17:24:36 +0100 > > IMO, it would be nice to paste your description below at the top of > go32-nat.c. Okay, I will do it some time soon. Btw, this single-process mode is also the reason why we need to play games with redir_to_child and redir_to_debugger: the file handles are also shared, so redirection on the "run" command line needs special handling (and there's no shell involved in interpreting it). > > So far so good. But the plot thickens if abnormal events happen, such > > as an exception inside the debuggee or just a Ctrl-C pressed by the > > user at a wrong time. We might get back to GDB before we had a chance > > to clean up after the debuggee. > > I see. To be clear, in this case, is the debuggee considered > dead and gone? No further debugging possible? That's the best we can do, yes. The debuggee is trashed. > But, notice one thing --- the go32_ops target > will still be pushed on the stack, and so the current target still is > considered to have execution (target_has_execution is true, and > inferior_ptid will still point at SOME_PID). So, when the user does "run", > GDB will ask if the user wants to kill the current program, and > will refuse to go ahead if the user says "no". If the user says > "yes", then, target_kill is called to kill the current program > (which ends up in go32_kill_inferior), all before reaching > go32_create_inferior. > > This is run_command->kill_if_already_running->target_kill. Then we probably can remove that conditional call to go32_kill_inferior. This is a very old code, perhaps at some past time it was necessary, I don't know. Given your description, it seems we don't need it anymore. > Currently, "kill" doesn't call `cleanup_client', after > my changes, it will --- I'm assuming that to be a good thing. Yes. > :-) I think that with my proposed change, we get the same ammount > of paranoia (even more), but, this needs to be at least minimally > tested, of course. I patched my snapshot with your changes, let me run with it for some time and see if anything goes wrong. You can commit the changes in the meantime. Thanks. Out of curiosity: why was normal_stop sentenced to death? > BTW, have you ever had any success running djgpp from inside an > emulator on linux, say, 'dosemu'? I never had time to set that up. Maybe DJ did.