Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com
Subject: Re: Building today's snapshot of GDB with MinGW
Date: Thu, 2 Jul 2020 10:30:00 -0400	[thread overview]
Message-ID: <a8818dc4-cb50-54a7-4c4f-ed5d62e195c0@polymtl.ca> (raw)
In-Reply-To: <9876615e-ab54-9fc4-4892-f855901e951e@polymtl.ca>

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


  reply	other threads:[~2020-07-02 14:30 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-29 18:27 Eli Zaretskii
2020-06-29 20:36 ` Christian Biesinger
2020-06-30 14:09   ` Eli Zaretskii
2020-06-30 22:24     ` Simon Marchi
2020-07-01 15:09       ` Eli Zaretskii
2020-07-02 13:50         ` Eli Zaretskii
2020-07-02 14:25           ` Simon Marchi
2020-07-02 14:30             ` Simon Marchi [this message]
2020-07-02 17:47               ` Eli Zaretskii
2020-07-02 14:40             ` Pedro Alves
2020-07-02 17:46               ` Eli Zaretskii
2020-07-02 18:21                 ` Pedro Alves
2020-07-02 18:33                   ` Eli Zaretskii
2020-07-02 18:34                     ` Pedro Alves
2020-07-01 15:20       ` Eli Zaretskii
2020-07-01 19:25         ` Christian Biesinger
2020-07-02  2:29           ` Eli Zaretskii
2020-07-02 10:18             ` Hannes Domani
2020-07-02 13:20               ` Eli Zaretskii
2020-07-06 10:39                 ` Hannes Domani
2020-07-06 16:35                   ` Eli Zaretskii
2020-07-01 19:25     ` Joel Brobecker
2020-07-02 13:46       ` Eli Zaretskii
2020-06-30 16:18 ` Eli Zaretskii
2020-06-30 18:21   ` Christian Biesinger
2020-06-30 18:28     ` Eli Zaretskii
2020-07-01 19:29   ` Joel Brobecker
2020-07-02  2:31     ` Eli Zaretskii
2020-07-01 19:30   ` Joel Brobecker
2020-07-02 13:39     ` Eli Zaretskii
2020-07-03 15:25       ` Joel Brobecker
2020-07-27  9:49         ` Tom de Vries
2020-07-27 10:05           ` Tom de Vries
2020-07-27 10:26             ` Tom de Vries
2020-07-27 11:48               ` [committed][gdb/build] Fix typo sys/sockets.h -> sys/socket.h Tom de Vries
2020-07-27 12:51                 ` Joel Brobecker
2020-07-27 14:18               ` Building today's snapshot of GDB with MinGW Eli Zaretskii
2020-07-02 14:12 ` Eli Zaretskii
2020-07-03 15:08   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a8818dc4-cb50-54a7-4c4f-ed5d62e195c0@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=brobecker@adacore.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@adacore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox