From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by server2.sourceware.org (Postfix) with ESMTPS id 7C8733940CDC for ; Sat, 7 Mar 2020 16:51:11 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 1D774270E26; Sat, 7 Mar 2020 11:51:10 -0500 (EST) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id L7VBgp3FPFkt; Sat, 7 Mar 2020 11:51:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 43730270E25; Sat, 7 Mar 2020 11:51:09 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 43730270E25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1583599869; bh=nlC81lzx05U9q6ar9vOLgCh1qRn0s/kGWcDXQDt4eRs=; h=To:From:Message-ID:Date:MIME-Version; b=Yb+MrBkAhmIMfrUcT/F6sZxmRLFxdlwLRO61xxbiFwodSdJQ8y5RZgLpbhvTWDuKg b7IOzo5E1CECx8RO31iqWAJl8DiuhlpVLz+K9y53IdOkEf/tQQX/ebYpsoU5DXTzP+ 4/sYFhsB2b2bjrEj0bGchcFqlPrJOq8vJoBo/I13LpSK2Cdns/hmG8+feuer3uTlQQ cD39EpJpqHuN62/SNX7ocfPACIL8E2EZcLGYW6oMYd25Edo/bKi1TMbhQYXEIt18Pi P/UO88qaba7QYuOL854Kb1TpclpYFgm+o5PC79c8IXQAlPNDspLPxgRz7D7SLLTM+G wav7ojTbPjSEQ== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 88QvMl1p_ZlN; Sat, 7 Mar 2020 11:51:09 -0500 (EST) Received: from [10.0.0.11] (unknown [192.222.164.54]) by mail.efficios.com (Postfix) with ESMTPSA id 2972F270E24; Sat, 7 Mar 2020 11:51:09 -0500 (EST) Subject: Re: [PATCH] gdb: recognize 64 bits Windows executables as Cygwin osabi To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20200307041742.31158-1-simon.marchi@efficios.com> <83zhcsa8my.fsf@gnu.org> From: Simon Marchi Message-ID: <4bd435cd-b06d-e0fc-70a9-9a8a18d73987@efficios.com> Date: Sat, 7 Mar 2020 11:51:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <83zhcsa8my.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 16:51:12 -0000 On 2020-03-07 3:09 a.m., Eli Zaretskii wrote: >> From: Simon Marchi >> Cc: Simon Marchi >> Date: Fri, 6 Mar 2020 23:17:42 -0500 >> >> When I load the 32 bits binary in my GNU/Linux-hosted GDB, the osabi is >> correctly recognized as "Cygwin": >> >> $ ./gdb --data-directory=data-directory -nx test_32 >> (gdb) show osabi >> The current OS ABI is "auto" (currently "Cygwin"). > > Why is this correct? Your debuggee is a MinGW program, not a Cygwin > program. The OS ABI should say "MinGW" or perhaps even "MS-Windows" > (since MinGW programs are just native Windows executables). As I said, I know that it's not absolutely correct. But having the native executable be detected as "Cygwin" seems relatively more correct compared to the current situation. The context is the following: https://sourceware.org/ml/gdb-patches/2020-03/msg00151.html Currently, loading the 64-bits .exe in a GNU/Linux-hosted GDB ends up calling the svr4 libraries code, which is plain wrong. By using the Cygwin osabi, at least the right shared libraries functions are used. I agree with what you suggest below, but I think that the current patch is still a step forward and improves things. > I'm guessing that this is some historical left-over: only Cygwin took > care of returning an OS ABI name at some point in the past, and we > never bothered to augment that for MinGW programs. I suggest that we > do TRT now, as long as we are on this subject. I think it makes sense and would avoid some confusion. I was surprised to see the Cygwin osabi used when debugging a native Windows program. > The difference between a Cygwin program and a native Windows program > is that the former has a dependency on the Cygwin DLL (or MSYS DLL, if > we want to support MSYS/MSYS2 executables). Is it possible to make > this distinction where we decide on the OS ABI? One question is, do we need this distinction at all? Let's look at where the Cygwin osabi comes into play. When the GDB_OSABI_CYGWIN osabi is detected, the "i386_cygwin_init_abi" function from i386-cygwin-tdep.c is called. In this function, I see nothing Cygwin-specific, all that is in there seems to apply equally to native Windows executables and Cygwin executables. So it seems like we could just rename the "Cygwin" osabi to "MS-Windows". Except that would be a breaking change, as the command "set osabi Cygwin" wouldn't work anymore. So what we can do is add an "MS-Windows" osabi and make "Cygwin" and "MS-Windows" functionally equivalent. Any "pei-i386" or "pei-x86-64" executable would be detected as "MS-Windows". We could try to detect whether the binary is using the cygwin or msys dll and if so apply the Cygwin osabi, but that would be just for aesthetic purposes, as the two osabis would be functionally equivalent (at least for now). It can still be useful to avoid confusion: if we have a Cygwin osabi, but Cygwin binaries are not recognized to use the Cygwin osabi, it just looks like a bug even if it isn't. I would need to dig into BFD and the PE/coff format to see how we could find this information. If we do such a change, I would like it to be done on top of the current patch, as to not mix concerns. > In any case, I see no reason to say that "pei-i386" executables are > necessarily Cygwin programs, the default should be "MS-Windows". Agreed. Simon