From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6ZoqG6eEFWpECx0AWB0awg (envelope-from ) for ; Tue, 26 May 2026 07:31:51 -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=ew0uTGH3; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 69C611E062; Tue, 26 May 2026 07:31:51 -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 0EAB91E062 for ; Tue, 26 May 2026 07:31:50 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 212284BA23FF for ; Tue, 26 May 2026 11:31:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 212284BA23FF 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=ew0uTGH3 Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id EE76D4BA23E8 for ; Tue, 26 May 2026 11:31:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EE76D4BA23E8 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 EE76D4BA23E8 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=1779795085; cv=none; b=TL7MZjT97OgcZcdlrIOegcTxE6/MF5Nyyj3AnkDGklGB2kLqi0/5bqj4XSjrf/8cBlTA323ZB3r3D/e1tz6QmYTmZxw8ZJr5WTatWVybT4cmuSInvHgbiXLSDlbR+SAPTdhGkQuEK8SlmnR3m5reW5VFJRHD+h+wgH2lXrenO2Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779795085; c=relaxed/simple; bh=RMGo5PzTsXHV3pE1Fy1KsN6oDnbEb3y3snmDctYkFnc=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=TiSKgZNKnAPaffyv81MsTfDGgqJYXeitoqENHcyCt25Y/Yrg5ocHTwD/0Tk4tYdA2ajrL9aq/REJyNIL9oOoZiWwuuORVhnUkdk5Xg2sKm8165D8L5LJbKZyIJ+CIpfEMND8ZeImx+6AL57uE+vq1GU+5YcIzZTMxmDTRp9kfww= 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=ew0uTGH3 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EE76D4BA23E8 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 1wRq0K-0000Zf-8A; Tue, 26 May 2026 07:31:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=r8dAwblDXUpU/lAMioudXzb/Z+gzc253gotR1zH02As=; b=ew0uTGH3GmbF Rz20AjidHliQvCyaGPIbtGYTfriD0A8ddwLe7+9REtjaU7n4rq6VwtdWH920/q832EQ6CuQpy28Gx QlLvuiZvlRsUk/eXTSjRf2xYoa0bqhic4zp/Iqi1uYri55r4fmkUOXhB7RJ7ehoNaAdB2CW+O4VuI hwMMIDjxunzeTHuoaCqZJLdvSFpZYMRMnp2ttJ6bnOPZ2NCwZhZm9e6RfSgtc59m2inMkfEodHtGP 89r4HGuY7y5C4l/QuGch0O2DUGbXJ+SK6TaFVQkTWg/gfu1D2obbfjdJA/rJC6oRMhcRB+EGGc+UA igZUb+CcNtjNNPKra4dWFA==; Date: Tue, 26 May 2026 14:31:19 +0300 Message-Id: <86h5nuquew.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <20260525191829.984105-9-pedro@palves.net> (message from Pedro Alves on Mon, 25 May 2026 20:18:26 +0100) Subject: Re: [PATCH v2 08/11] Windows gdb+gdbserver: Decode Cygwin ExitProcess codes References: <20260525191829.984105-1-pedro@palves.net> <20260525191829.984105-9-pedro@palves.net> 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: Mon, 25 May 2026 20:18:26 +0100 > > +void > +windows_process_info::maybe_note_cygwin1_dll (const char *dll_path) > +{ > + const char *base = dll_path + strlen (dll_path); > + while (base > dll_path && base[-1] != '/' && base[-1] != '\\') > + base--; > + if (strcasecmp (base, "cygwin1.dll") == 0) > + cygwin1_dll_loaded = true; > +} I wonder if this should also detect the MSYS2 DLL, since (AFAIU) MSYS2 is a fork of Cygwin. But I don't know what is the status of GDB support for debugging MSYS2 executables. > + /* The inferior may also exit with a raw NTSTATUS error code, e.g., > + STATUS_ACCESS_VIOLATION (0xc0000005), without going through the > + pinfo::exit at all -- for example, if the unhandled-exception > + filter didn't run, or for processes that don't link cygwin1.dll. > + Detect those and map them the same way Cygwin's set_exit_code > + does in winsup/cygwin/pinfo.cc. */ > + if (exit_code >= 0xc0000000) > + { > + gdb_signal sig; > + switch (exit_code) > + { > + case EXCEPTION_ACCESS_VIOLATION: > + sig = GDB_SIGNAL_SEGV; > + break; > + case EXCEPTION_ILLEGAL_INSTRUCTION: > + sig = GDB_SIGNAL_ILL; > + break; > + case STATUS_NO_MEMORY: > + sig = GDB_SIGNAL_BUS; > + break; > + case STATUS_CONTROL_C_EXIT: > + sig = GDB_SIGNAL_INT; > + break; > + default: > + /* Cygwin maps any other NTSTATUS to exit 127. */ > + tstatus.set_exited (127); > + return tstatus; > + } > + tstatus.set_signalled (sig); > + return tstatus; > + } This seems to be a subset of what windows_status_to_termsig already does, or thereabouts. Did you intentionally used separate and slightly different code, and if so, why? Perhaps the reason should be in the commentary? > + /* Note: when GDB attaches to a Cygwin inferior and the inferior is > + then killed externally (e.g., taskkill /F with exit code 1), GDB > + and Cygwin disagree. Cygwin's parent waitpid reports WIFEXITED, > + code=1; GDB reports SIGHUP (signal 1, no swap below because > + started_by_cygwin). Cygwin's parent distinguishes "pinfo::exit > + ran" from "didn't run" via the child's wait pipe and only applies > + the swap-undo for the former. GDB has only dwExitCode and can't > + tell. This can't be solved without Cygwin's help. OTOH, such an > + external termination steps out of Cygwin and arguably falls into > + undefined-behavior territory, so it is less important than the > + other cases. */ This should be arguably reported to Cygwin developers, but until they fix this, I wonder whether assuming that SIGHUP is much more rare than TASKKILL (or any other way of natively killing a program on Windows), and handle 1 as an exit code rather than a signal, will be more useful in practice? Thanks. Reviewed-By: Eli Zaretskii