From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id gyLTLqICEGq7ag4AWB0awg (envelope-from ) for ; Fri, 22 May 2026 03:15:46 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=g+FUld7o; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id ACCC51E062; Fri, 22 May 2026 03:15:46 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 70B401E062 for ; Fri, 22 May 2026 03:15:42 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 303CD48F60F6 for ; Fri, 22 May 2026 07:15:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 303CD48F60F6 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=g+FUld7o Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 7CB6348F5366 for ; Fri, 22 May 2026 07:15:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7CB6348F5366 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7CB6348F5366 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779434112; cv=none; b=TxxqOP4kYklN11T6/roD3ZEc7E2sAu04R/p7SYXLStV1bVzm8td4r9OJ2cIRWwhhp9ciU+cfVxudkj7suS3CuJTsQTxk4sHL9Kox6Njp7nL8tQ0AJE5k0S3PkY/kLGa2POxX6LKdktdjKlb51R0CMowCYuGLM0oAOCyQ8ZXvwfA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779434112; c=relaxed/simple; bh=ntzTChRXWAVQgHZ3OGXHj2BBOxdv/yQBMbkrY0+TlO4=; h=DKIM-Signature:Date:Message-Id:From:To:Subject:MIME-version; b=NolagUGLdAmTaNU/oAtZE2996fuWVSeNyH4Spuf7a8SC/6vAtLaZm4ovsIdEJPV66o0yw8wo1rvewEAvfg56ePv9krnfE1dPR/+yu4bnZqg99TECbbHTZ54DrVRLLBdSloI/jUE/8Ur1px5AoGafOET4q3Pgzr4HjJjKi0NCr3Q= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=g+FUld7o DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7CB6348F5366 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wQK6A-0002NR-RG; Fri, 22 May 2026 03:15:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=MQrUyb5tJWn5VpGONkLw+PhYkPgqzLGFWwaryo8brxg=; b=g+FUld7oGJB3nNXk/XdL vrXdJYAe1kL5vLN21ZuyqYELKxv7j3Tty3467JCZuxor9LbEMownhSdxhNHTwjqW9+KZOum0vfVes U9z4BZsjVYsK7yf7aJQmHMZ1LUQal+w0EewABQoINe9OK+J+gJmCjzNJXqXcWQM/1tvvCSgJ1JZmF Y1DLocjB+ma3LHUxMq18CpSFHMA6fUmasCJsbXY/yP8jTszA5faPlmCrprTnVLBYLgMoh1r6Otveh vjygMbp34pLGSiOoVa1nsrGIXtA50utZyrPCRQxGjxTFnSNx3yTJoblRNswt4i5PDkpo7vHjgUHB0 XMHjsaKUwjwEIQ==; Date: Fri, 22 May 2026 10:15:06 +0300 Message-Id: <86se7jykxx.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <20260522001626.393908-5-pedro@palves.net> (message from Pedro Alves on Fri, 22 May 2026 01:16:25 +0100) Subject: Re: [PATCH 4/5] Fix exit/signal code on Cygwin References: <20260522001626.393908-1-pedro@palves.net> <20260522001626.393908-5-pedro@palves.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org > From: Pedro Alves > Date: Fri, 22 May 2026 01:16:25 +0100 > > I noticed that on native Cygwin, gdb.python/py-events.exp has this: > > [Thread 15952.0x534 (id 1) exited with code 12] > ... > Program terminated with signal SIGSYS, Bad system call. > ... > (gdb) FAIL: gdb.python/py-events.exp: Inferior 1 terminated. > > The program exits with normal exit code 12, not a signal. SIGSYS is > 12. > > Similarly, gdb.base/exitsignal.exp has this: > > continue > Continuing. > [Thread 15220.0x219c (id 1) exited with code 2816] > [Thread 15220.0x3a50 (id 3) exited with code 2816] > [Thread 15220.0x25a0 (id 4) exited with code 2816] > [Inferior 1 (process 15220) exited with code 05400] > (gdb) FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV (the program exited) > > Here, the program exits with SIGSEGV, not normal exit code 2816 (05400 > in octal). > > The problem is that gdb/windows-nat.c does not know about Cygwin's > exit codes as seen from the native Windows side. Same for gdbserver's > win32-low.c. > > This commit fixes it. To avoid duplicating code, it adds a new > native_exit_code_to_target_status function in nat/windows-nat.c used > by both GDB and GDBserver, with the MinGW-specific logic added by > commit 559e7e5056 ("Improve process exit status macros on MinGW") > moved there too. AFAIU, this basically adds a Cygwin-specific branch to the code that determines the terminating signal and status of a program, leaving the code for the native Windows and MinGW programs intact. I suggest to say this in the commit log message, because as written, it sounds like it does something for Cygwin that is not done for MinGW. Which is not true. > +#ifdef __CYGWIN__ > + /* /usr/include/cygwin/wait.h explains that a wait status is 16 > + bits, and looks like: > + > + "<1 byte info> <1 byte code> > + == 0, child has exited, info is the exit value > + == 1..7e, child has exited, code is the signal number. > + == 7f, child has stopped, info was the signal number. > + == 80, there was a core dump." > + > + However, when passing the wait status to native ExitProcess as a > + native exit code, cygwin1.dll swaps the / bytes. > + Swap them back into a wait status here. */ > + int wstatus = ((exit_code & 0xff) << 8) | ((exit_code >> 8) & 0xff); Should the commentary say something about _why_ we swap the bytes here? I know very little about Cygwin, but my naïve view is that when a Cygwin program is run from another Cygwin program, no such swapping should be needed, is that right? One should just use the macros from the sys/wait.h header, right? If so, why do we need to swap the bytes here, and how is "passing the wait status to native ExitProcess as a native exit code" relevant to what this part of GDB needs to do? Other than these questions, the MinGW part of the code looks okay to me, thanks. Reviewed-By: Eli Zaretskii