From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by server2.sourceware.org (Postfix) with ESMTPS id 40D483877030 for ; Sat, 7 Mar 2020 18:16:23 +0000 (GMT) Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0E4A31E5F3; Sat, 7 Mar 2020 13:16:21 -0500 (EST) Subject: Re: [PATCH] gdb: recognize 64 bits Windows executables as Cygwin osabi To: Eli Zaretskii , Simon Marchi Cc: gdb-patches@sourceware.org References: <20200307041742.31158-1-simon.marchi@efficios.com> <83zhcsa8my.fsf@gnu.org> <4bd435cd-b06d-e0fc-70a9-9a8a18d73987@efficios.com> <835zfg9hz5.fsf@gnu.org> From: Simon Marchi Message-ID: Date: Sat, 7 Mar 2020 13:16:21 -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: <835zfg9hz5.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, SPF_HELO_PASS, 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 18:16:24 -0000 On 2020-03-07 12:45 p.m., Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Simon Marchi >> Date: Sat, 7 Mar 2020 11:51:08 -0500 >> >> 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 agree. I just think we can do better. > >> 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". > > That's fine with me, and IMO will be more accurate than calling them > all "Cygwin", since Cygwin programs are just a peculiar kind of > Windows executables. Ok, I can make a second patch that introduces this new "MS-Windows" osabi. > >> If we do such a change, I would like it to be done on top of the current >> patch, as to not mix concerns. > > I'm okay with that, thanks. > I looked up some information about how PE executables list their DLL dependencies, apparently it's in the ".idata" section. There is some doc here: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-idata-section and here: https://blog.kowalczyk.info/articles/pefileformat.html#9ccef823-67e7-4372-9172-045d7b1fb006 With that, I was able to parse enough of .idata in a very crude way (consider it just a prototype) and get the DLL names. I noticed that there is some BFD code that also parses it: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/peXXigen.c;h=e42d646552a0ca1e856e082256cd3d943b54ddf0;hb=HEAD#l1261 however, it's coupled with the printing code, so not very easy to re-use. Ideally, one would refactor this code to provide a nice BFD interface to look up this information, but I don't really have time for that. I wrote to the binutils mailing list (sourceware is in maintenance right now so I can't provide the archive link) to ask what we can do about that. Simon