From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 4CCDD3858D34 for ; Thu, 2 Jul 2020 17:46:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4CCDD3858D34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eliz@gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]:37422) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jr3Hv-0000wH-Ht; Thu, 02 Jul 2020 13:46:19 -0400 Received: from [176.228.60.248] (port=4444 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jr3Hr-0007bR-CD; Thu, 02 Jul 2020 13:46:19 -0400 Date: Thu, 02 Jul 2020 20:46:14 +0300 Message-Id: <83pn9dx121.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: simon.marchi@polymtl.ca, tromey@adacore.com, brobecker@adacore.com, gdb-patches@sourceware.org In-Reply-To: <76a315f9-ed60-93b4-10ab-95bc3bc8ae64@palves.net> (message from Pedro Alves on Thu, 2 Jul 2020 15:40:20 +0100) Subject: Re: Building today's snapshot of GDB with MinGW 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> <76a315f9-ed60-93b4-10ab-95bc3bc8ae64@palves.net> X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, 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 17:46:22 -0000 > Cc: tromey@adacore.com, brobecker@adacore.com, gdb-patches@sourceware.org > From: Pedro Alves > Date: Thu, 2 Jul 2020 15:40:20 +0100 > > > 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). Thanks. AFAIK, this is impossible on Windows: a 64-bit debugger can debug 32-bit programs (and I think GDB recently learned how to do that), but a 32-bit debugger cannot debug 64-bit programs.