From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29313 invoked by alias); 20 Jan 2010 16:41:42 -0000 Received: (qmail 29297 invoked by uid 22791); 20 Jan 2010 16:41:40 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Jan 2010 16:41:35 +0000 Received: (qmail 6145 invoked from network); 20 Jan 2010 16:41:33 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Jan 2010 16:41:33 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] windows: do not crash if inferior Date: Wed, 20 Jan 2010 16:41:00 -0000 User-Agent: KMail/1.9.10 Cc: Joel Brobecker , Tristan Gingold References: <1C9A707A-AE7C-4947-A9DA-F105674F81AE@adacore.com> <20100119092227.GN17397@adacore.com> In-Reply-To: <20100119092227.GN17397@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201001201641.45826.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: 2010-01/txt/msg00503.txt.bz2 On Tuesday 19 January 2010 09:22:27, Joel Brobecker wrote: > I don't see a "generic" way of dealing with this situation. =A0So the type > of approach you took (returning early from do_initial_windows_stuff) > seems to be the only approach I can see. I was initially a little > reluctant about throwing an error: As far as I can tell from the code, > the debugger should have already printed an error message such as > "Inferior exited with code ..." (is that correct?) - and so an extra > "inferior exited early" message could be considered superfluous. However, > if you do not error-out now, core GDB will assume that target_create_infe= rior > succeeded and thus possibly do something unexpected as well. >=20 > Bottom line - I cannot propose a better approach short of revamping > a bit the target_create_inferior routine to add error-handling, > I think the patch is fine. IMO, the clean and proper solution is to stop using wait_for_inferior from within target_create_inferior, similarly to fork-child.c:startup_inferior --- fork-child.c:startup_inferior handles the similar case of the inferior process exiting early during startup before being fully properly created. --=20 Pedro Alves