Building today's snapshot of GDB with MinGW

[Simon Marchi]

On 2020-07-02 10:25 a.m., Simon Marchi 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         ;;
> 
> 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.

In fact, we should probably do it, otherwise it's confusing.  You build GDB
for Windows, GDB claims that it supports x86-64, since you can set it using
"set architecture":

  (gdb) set architecture
  auto               i386               i386:intel         i386:x64-32        i386:x64-32:intel  i386:x86-64        i386:x86-64:intel  i8086

But that's not really helpful because that GDB doesn't know about Windows
on x86-64:

  (gdb) set architecture i386:x86-64
  warning: A handler for the OS ABI "Windows" is not built into this configuration
  of GDB.  Attempting to continue with the default i386:x86-64 settings.

  The target architecture is assumed to be i386:x86-64

Simon