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 F41823858D37 for ; Tue, 30 Jun 2020 22:24:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F41823858D37 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 05UMOC5o008314 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 18:24:17 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 05UMOC5o008314 Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id F137B1E797; Tue, 30 Jun 2020 18:24:11 -0400 (EDT) Subject: Re: Building today's snapshot of GDB with MinGW To: Eli Zaretskii , Christian Biesinger , Tom Tromey , Joel Brobecker Cc: gdb-patches@sourceware.org References: <83a70l20dn.fsf@gnu.org> <83wo3ozlvn.fsf@gnu.org> From: Simon Marchi Message-ID: <56f26808-dfb0-6703-6f1f-9818c35946dd@polymtl.ca> Date: Tue, 30 Jun 2020 18:24:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <83wo3ozlvn.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 30 Jun 2020 22:24:12 +0000 X-Spam-Status: No, score=-7.7 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: Tue, 30 Jun 2020 22:24:46 -0000 On 2020-06-30 10:09 a.m., Eli Zaretskii wrote: >>> 4. Running "maint selftests" produces several warnings and failures: >>> >>> 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. >> >> Possibly related to >> https://sourceware.org/pipermail/gdb-patches/2020-March/166678.html ? > > Simon, any chance you could look into this, or instruct me how to > investigate? I built a GDB on Linux with a MinGW target and ran the self tests. I got: warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB. Attempting to continue with the default i386:x64-32 settings. warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB. Attempting to continue with the default i8086 settings. warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB. Attempting to continue with the default i386:x64-32:intel settings. These are pretty much expected. For the "gdbarch selftests", we run some test using all the arches known to BFD. When initializing the gdbarch for these architectures, the default osabi for that version of GDB is assumed (in gdbarch_info_fill). In your GDB or the GDB I compiled, the default osabi is Windows. When trying to initialize that gdbarch, GDB just complains that it doesn't have support for debugging Windows programs running on i386:x64-32, i386:x64-32:intel and i8086. This is expected, as i386:x64-32 is an ABI not supported by Windows. And I presume i8086 is the very old Intel architecture, which obviously does not support Windows. However, some of the warnings you get are not expected: 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. warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB. Attempting to continue with the default i386:x64-32 settings. warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB. Attempting to continue with the default i8086 settings. 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:intel settings. warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB. Attempting to continue with the default i386:x64-32:intel settings. 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:nacl settings. warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB. Attempting to continue with the default i386:x64-32:nacl settings. 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). Simon