Building today's snapshot of GDB with MinGW

[Pedro Alves]

On 7/2/20 3:25 PM, Simon Marchi via Gdb-patches wrote:
> On 2020-07-02 9:50 a.m., Eli Zaretskii wrote:
>>> Date: Wed, 01 Jul 2020 18:09:11 +0300
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com
>>>
>>>> We would not expect GDB to complain for Windows on i386:x86-64.
>>>>
>>>> The first thing I would do is make sure that the function _initialize_amd64_windows_tdep
>>>> gets executed at startup in your GDB.  This is the function that registers a handler for
>>>> the tuple (i386:x86-64, Windows).
>>>
>>> Thanks, I will take a look there and report what I see.
>>
>> I started looking at the code, but then I had a eureka moment.  You
>> mentioned _initialize_amd64_windows_tdep, so I presume you assumed my
>> build is a 64-bit one?  It isn't: it's a 3--bit build, and thus
>> _initialize_amd64_windows_tdep is not even compiled into the binary.
>>
>> Given that my build is a 32-bit one, it sounds expected to see
>> warnings I cited, as they all complain about 64-bit architectures,
>> right?
>>
>> Incidentally, I wonder why the gdbarch selftest is trying
>> architectures that are not supported and not even compiled in.  What
>> is the purpose of doing that?
> 
> It loops over all the architectures known to bfd.  So I suppose that in BFD,
> enabling support for i386 enables support for x86-64, that it all comes
> together.  But in GDB, when configuring GDB for a Windows i386 target, we
> don't add support for Windows x86-64 targets.  So the warnings you see make
> sense.
> 
> I noticed that when configuring GDB for an i386/Linux target, we also throw
> in support for amd64/Linux as well if $enable_64_bit_bfd is true (which allows
> a 32-bit program to read a large > 4GB executable, I suppose):
> 
> 290 i[34567]86-*-linux*)
> 291         # Target: Intel 386 running GNU/Linux
> 292         gdb_target_obs="i386-linux-tdep.o \
> 293                         glibc-tdep.o \
> 294                         solib-svr4.o symfile-mem.o \
> 295                         linux-tdep.o linux-record.o"
> 296         if test "x$enable_64_bit_bfd" = "xyes"; then
> 297             # Target: GNU/Linux x86-64
> 298             gdb_target_obs="amd64-linux-tdep.o ${gdb_target_obs}"
> 299         fi
> 300         ;;
> 

This is so a i686-linux-gnu hosted toolchain works with 64-bit binaries.
There are vendors who prefer (or used to prefer, time has passed
and don't know if that's still a thing) it that way, as it's a single
build for 32-bit and 64-bit hosts that way.   Users can then build
64-bit apps with e.g., "i686-unknown-linux-gnu-gcc -m64".  Naturally,
the debugger follows suit (though that's only useful for cross debugging,
since for native debugging 64-bit inferiors, you need a 64-bit debugger).

See:

https://sourceware.org/legacy-ml/gdb-patches/2009-04/msg00420.html

> We could perhaps do the same for Windows, I don't think there would be any
> downsides to it, and it could be useful to some people.
>