From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EbWqOkt9FGpspBkAWB0awg (envelope-from ) for ; Mon, 25 May 2026 12:48:11 -0400 Received: by simark.ca (Postfix, from userid 112) id EBB691E0A3; Mon, 25 May 2026 12:48:11 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 66D1F1E024 for ; Mon, 25 May 2026 12:48:11 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EABDA4BA23ED for ; Mon, 25 May 2026 16:48:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EABDA4BA23ED Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by sourceware.org (Postfix) with ESMTPS id 286C74BA798D for ; Mon, 25 May 2026 16:47:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 286C74BA798D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 286C74BA798D Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.45 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779727665; cv=none; b=LoxJ3KD25q4VUEJgI4I8ibrL3AI6+yfwgqkgyIFnPSxmGZSsuxGmlLwt5E+9D9aElyV4wiKdYrvP8lTQgMv+KUDTJkioVl1HarrtYcw5zKr9s4nnBlwXJ0WggUelXODIQ+GiNtT8J/KJP/+tDLMrGhRaVJrlnSYfStdAj8XJRbw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779727665; c=relaxed/simple; bh=1EXc2C4R0MAP9QVR7cypPG4R37Itw3nSvhLzkxdtnuI=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=SLSsInjgTXfSE9FAWJuzWupvlpG2yERKgmPQwx2ph56jJpMqH6ebZD3nI8nE920qEdOL7pkCXQF3VcomeKCrRMi1rVPSUU96H8kMnzfKGhEAjqpYQO54S9WXnESzWH40UWWN/rgMsRFMgh/xvXhl+5nogJxHZgrJ3iCGk8SIMy4= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 286C74BA798D Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49040362e4aso40481925e9.0 for ; Mon, 25 May 2026 09:47:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779727664; x=1780332464; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZBSRUdFlPXAPyIa1pJwc3K0h/+ZUVDQGuOauMDns/60=; b=Wokde5FI8BSaGiW5ml2IyPPwF9r1lgIcmZHYBqf4o8gMxSOG9gST71iPHV/gHrq/0B Zyg1VBh5tijxVNVxVNnz/p71sQO/HdyFctZvkG8eo7UBPsaV7BQtDL5zmsddda4LAJ7R mDRstSUFQgpulIX8Vje8SAuvTWfMFDfcQolP4uGO8C1kbGlaZ8Smp5IDPUsp6PBR4mJA 39egYdnObyaLHCp84cd3wjo6/59xGMUvp62GMD0oNXxVeCy5epL4p+ojp4yynKQ3IFZT QA3yV/QuOsltkYXD+bwm+Cqljy6ZwO80dMpVyqMoZHmyvl8kTTjOqsgl7MSJyqYGN2j1 F4uw== X-Gm-Message-State: AOJu0Yx+PrB68SFovsr9j0DWJOk43tEyNBKyxfpP+ndnSvN1d89hWPM4 w6QIivmLt4/tNB/FmwQLtgs/rn6+wXx5ZkJYhqRaPyapAOBC3e4Jjq/dqmaL0A== X-Gm-Gg: Acq92OEDwcA6mSN8RWvPDPcB/FJk3LY+oUlnjDbXVPyxuYCi4DT0mt1/D3IYf8jY8vQ VgsFzdk64WndO/9N+kpyWp2DZt4XxxNTFZi+kbYv5FCrgeMLrh37YSTSIFxyiI1CeLbfKo5kMXT bRuEhqQOYLbnttPZYu1EQWynDO7Oq70EFRhKjbVHLtVmUnO69/mtUcxwG8Nomlw297JYORAEy9n CD6mn3b27PNKozj2Jz4RyXxi3OGUg2ksZ6vhqMYo0FtATNew6/+4qTW/bHt0pSqcBdcYqI9lFKR RSKPCE6sMliM8fCJH84KcuHiXjtQPAS7KzlOsteXahdbK5hBiLZMFNd8plSVqw/lO0mbcVqE4+s 2ohkP6mIvBs6zVnpS2Vtb3sfZ85yU8D8k0e4f46Kpd2Ud3flGe8wT+IsKjM/IvRpMjwidY4VLBu vFulniSp4oX3KWOPYvUq098xUUBlVKr6+hvorSDUDSf612NwLHUYwRkbOTBX7zhQ1DxxyZfD3g7 8Yy X-Received: by 2002:a05:600c:4e43:b0:48f:e230:2a1d with SMTP id 5b1f17b1804b1-49042ae77b4mr267313085e9.32.1779727663796; Mon, 25 May 2026 09:47:43 -0700 (PDT) Received: from ?IPV6:2001:8a0:fae3:2600:dc16:ec0f:632c:5ba7? ([2001:8a0:fae3:2600:dc16:ec0f:632c:5ba7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45eb6c9f6ffsm28617073f8f.1.2026.05.25.09.47.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2026 09:47:43 -0700 (PDT) Message-ID: <2f04d0f3-38dd-4941-a767-59c5119d97cb@palves.net> Date: Mon, 25 May 2026 17:47:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/5] Fix exit/signal code on Cygwin To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20260522001626.393908-1-pedro@palves.net> <20260522001626.393908-5-pedro@palves.net> <86se7jykxx.fsf@gnu.org> From: Pedro Alves Content-Language: en-US In-Reply-To: <86se7jykxx.fsf@gnu.org> 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 On 2026-05-22 08:15, Eli Zaretskii wrote: >> From: Pedro Alves ... >> 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. Yes. For v2, I split the refactor to its own patch, which I think makes that more obvious. > 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. Done this too, thanks. > >> +#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? Thanks for raising the question, it made me look deeper, dig into the Cygwin code in mode detail, and realize that in the attach case, we shouldn't do the swap. v2 has more and better comments explaining all this, as well as handling the attach case, and testing it too. The new comments will implicitly answer your questions. I'll be sending v2 shortly to the list. Pedro Alves > > Other than these questions, the MinGW part of the code looks okay to > me, thanks. > > Reviewed-By: Eli Zaretskii >