From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28184 invoked by alias); 16 Nov 2012 08:18:21 -0000 Received: (qmail 28171 invoked by uid 22791); 16 Nov 2012 08:18:18 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Nov 2012 08:18:12 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDK00800MVN7500@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 16 Nov 2012 10:18:10 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDK005N1N2AWP41@a-mtaout22.012.net.il>; Fri, 16 Nov 2012 10:18:10 +0200 (IST) Date: Fri, 16 Nov 2012 08:18:00 -0000 From: Eli Zaretskii Subject: Re: [10/10] RFC: remove gdb_wait.h In-reply-to: <20121115210828.GG3790@adacore.com> To: Joel Brobecker Cc: tromey@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83txsqrmfu.fsf@gnu.org> References: <87obiyzns7.fsf@fleche.redhat.com> <87wqxmwthq.fsf@fleche.redhat.com> <83wqxmsi32.fsf@gnu.org> <20121115210828.GG3790@adacore.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: 2012-11/txt/msg00455.txt.bz2 > Date: Thu, 15 Nov 2012 13:08:28 -0800 > From: Joel Brobecker > Cc: Tom Tromey , gdb-patches@sourceware.org > > > This could break the MinGW build some day, or maybe even today: its > > definition of WIFSIGNALED and WIFEXITED is inaccurate for Windows. > > > > I say "some day" because it looks like we don't actually use > > WIFSIGNALED in any file that is compiled on Windows (not sure about > > WIFEXITED, though). > > In that case, let's be proactive and contribute a patch to gnulib? > You seem to know what the problem is, so you'd be the best candidate. With my previous Windows-related contribution to gnulib collecting dust since January, without any reason (the RM agreed that the code was correct and should be admitted), why would I bother to submit another one? The problem is that the definition of WIFSIGNALED is naive and incorrect for most Windows programs. It will cause any program that does "exit(3);" be considered as exited due to a signal SIGTERM. And WIFEXITED, being defined as everything but WIFSIGNALED, is consequently also incorrect. The truth is described in the MSDN documentation of GetExitCodeProcess: If the process has terminated and the function succeeds, the status returned is one of the following values: . The exit value specified in the ExitProcess or TerminateProcess function. . The return value from the main or WinMain function of the process. . The exception value for an unhandled exception that caused the process to terminate. This is how I translated this documentation in my port of GNU Findutils: #define WEXITSTATUS(w) ((w) & ~0xC0000000) #define WIFEXITED(w) (((w) & 0xC0000000) == 0) #define WTERMSIG(w) (w) #define WIFSIGNALED(w) (((w) & 0xC0000000) != 0) #define WIFSTOPPED(w) (0) To produce a human-readable description of WTERMSIG, one then needs to compare its value with the EXCEPTION_* macros defined on winbase.h header in the w32 API headers, or convert them to Posix signals like what handle_exception in windows-nat.c and in win32-low.c do. E.g., the value 0xc0000005 means Access Violation, a.k.a. "SIGSEGV".