From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 31326384402D for ; Thu, 2 Jul 2020 14:30:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 31326384402D Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 062EU0sr011566 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Jul 2020 10:30:05 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 062EU0sr011566 Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (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 92F161E5F9; Thu, 2 Jul 2020 10:30:00 -0400 (EDT) Subject: Re: Building today's snapshot of GDB with MinGW From: Simon Marchi To: Eli Zaretskii Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com References: <83a70l20dn.fsf@gnu.org> <83wo3ozlvn.fsf@gnu.org> <56f26808-dfb0-6703-6f1f-9818c35946dd@polymtl.ca> <83pn9fxofc.fsf@gnu.org> <83v9j6vxey.fsf@gnu.org> <9876615e-ab54-9fc4-4892-f855901e951e@polymtl.ca> Message-ID: Date: Thu, 2 Jul 2020 10:30:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9876615e-ab54-9fc4-4892-f855901e951e@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 2 Jul 2020 14:30:00 +0000 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP 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: Thu, 02 Jul 2020 14:30:13 -0000 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 >>> 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