[PATCH] gdb: recognize 64 bits Windows executables as Cygwin osabi

[Simon Marchi]

On 2020-03-07 12:45 p.m., Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: Simon Marchi <simon.marchi@efficios.com>
>> 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