From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68368 invoked by alias); 17 Dec 2019 17:51:34 -0000 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 Received: (qmail 68354 invoked by uid 89); 17 Dec 2019 17:51:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Dec 2019 17:51:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576605090; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UZCdswT8pIC3v+vCbCD5aEMByQqqh8XyBUyuhUIBaKU=; b=UTOYKACJaY0b2Mdp6q5LGS8sqgHx10b7lEqga4MfoZW3Jqs1I+r2BZu3jWVru8LwUd3fp5 Tz61U4psFBuku2mP9di1wVF1LN/E7Au2h7tlDEO/yv5rcSzaCJpk9Jq837Egap8adTgE40 q+6OYFlYWTbR4QWvxRxDlP6LOK0d+sQ= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-144-gqHoZ6k3NkCDG9N8zUg_XQ-1; Tue, 17 Dec 2019 12:51:29 -0500 Received: by mail-wr1-f70.google.com with SMTP id b13so4250626wrx.22 for ; Tue, 17 Dec 2019 09:51:29 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id f207sm4213242wme.9.2019.12.17.09.51.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Dec 2019 09:51:27 -0800 (PST) Subject: Re: [RFAv3 2/6] Improve process exit status macros on MinGW To: Eli Zaretskii References: <20190504161753.15530-1-philippe.waroquiers@skynet.be> <20190504161753.15530-3-philippe.waroquiers@skynet.be> <835zie51mf.fsf@gnu.org> Cc: philippe.waroquiers@skynet.be, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <52c4ca33-ffc4-8e1e-fe08-a92123ef02aa@redhat.com> Date: Tue, 17 Dec 2019 17:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <835zie51mf.fsf@gnu.org> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-12/txt/msg00749.txt.bz2 On 12/17/19 4:59 PM, Eli Zaretskii wrote: >> From: Pedro Alves >> Date: Mon, 27 May 2019 18:33:11 +0100 > > To recap, back in May Philippe added the 'pipe' command, and we had a > brief discussion regarding the use of WIFEXITED, WIFSIGNALED, and > other related macros from , on MS-Windows. It was decided > back then to leave for later the translation of exit codes returned by > 'pipe' in MS-Windows build of GDB. > > I've now started to look at this issue, with the intent to provide ext > status to signal conversion for the MS-Windows ports of GDB, and I > have a few questions regarding the details. > > In that discussion, Pedro commented on Philippe's proposed patch > (https://sourceware.org/ml/gdb-patches/2019-05/msg00131.html) which > added the definitions for WIF* and WEXIT* macros to gdb_wait.h and > their use in widnows-nat.c. The comments are in > https://sourceware.org/ml/gdb-patches/2019-05/msg00590.html, and go > like this: > >>> * common/gdb_wait.h (WIFEXITED, WIFSIGNALED, WEXITSTATUS, >>> WTERMSIG): Define better versions for MinGW. >>> * windows-nat.c (xlate): Uncomment the definition. >>> (windows_status_to_termsig): New function. >> >> windows-nat.c looks like the wrong place to put this. >> >> windows-nat.c is only included in the build if building a native >> debugger. But, you need this functionality on every Windows-hosted build >> of GDB, even cross debuggers. So I think you're breaking the build on >> the Windows-hosted, non-native-debugger case. >> >> E.g., --host=mingw --target=arm-none-eabi. >> >> The right place would be mingw-hdep.c. > > I'm okay with doing this in mingw-hdep.c, but I'm a bit confused by > this comment. The encoding of the fatal exception in the exit status > of a program is a feature of the native MS-Windows processes. Does > "running cross-debugger" mentioned above allude to running an > MS-Windows program? The issue pointed out was that by putting the windows_status_to_termsig function in windows-nat.c, and then calling it from gdb's common code (cli/cli-cmds.c, via WTERMSIG) would result in a build/link failure when you try to build a cross debugger hosted on mingw, because such a gdb build does not include the native Windows target support, i.e., does not build/link the windows-nat.o object. Putting said function in mingw-hdep.c instead fixes that issue because that file is included as part of the build in all kinds of mingw-hosted GDBs, either native or cross-debugger. >> I admit to being a bit confused about why we want to do this >> translation for this feature while we don't do it for the exit code >> of inferiors running under gdb, for example. I mean, exit status >> with 0xc0000000 set don't cause $_exitsignal to be set instead of >> $_exitcode. > > Yes, we should do this for exit code of inferiors as well. > > Native MS-Windows debugging produces the TARGET_WAITKIND_* values in > windows-nat.c, so I think the conversion we are talking about will > have to be done there, perhaps _in_addition_to_ other places? IOW, > the function that performs the conversion can be defined in > mingw-hdep.c, but it will have to be called from windows-nat.c at > least, right? And I'm uncertain what other places will have to call > that conversion function for the use case of running a cross-debugger, > can someone please help me understand that? You'll also want to call it in gdbserver's win32-low.c file, so that you get the translation too when debugging against gdbserver. This actually suggests putting the new function in some new shared file in gdb/gdbsupport/, since gdb/mingw-hdep.c is gdb-only. Thanks, Pedro Alves