From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by sourceware.org (Postfix) with ESMTPS id 0F3F2384402D for ; Thu, 2 Jul 2020 14:40:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0F3F2384402D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wm1-f65.google.com with SMTP id l2so26768231wmf.0 for ; Thu, 02 Jul 2020 07:40:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ahBjxCuqyKD7LQi808MikB5msolsqOZUhR5PnPGMdl4=; b=IXmREvHKyTO4f+Oq5Or4DBY76yFM3NXzRcc0zezDpMfc0V1WsrRJRBVsng2wqi3wPa vMOnw+xJfYCbrfU9+YrcnQcbQmYW3h3JoRK91mMxF40jgnuSM+enM+DobQWJCC7+Q+yp xC8xKvSnqnoj+zU3OtpxRZkUemtmEszvB86S7CD/0KTE6yXMr0OesB0l87e6VvUYFT06 6X0rMXpFD9Yr+LK+priNmXfQE06RDhjCNrrKzZrxwO2hzTdadbsq8d6DnfhJ+c52WwoP n9hEAc567FzCkYAgDbdLgDDr+aGFQZeCsXx8DeOEKmbYJiouh8DVFei6GC+9s1pdhgeA cGfw== X-Gm-Message-State: AOAM531OXk+pw5mgjszVlUWAhFHMQ5rijM/AUa17MGgEYIzMYgq8jjyg k8uo2Qb1C/EzeblzppHgDUFZRA0jvmaEBg== X-Google-Smtp-Source: ABdhPJy296Q0o750/Zb5noAZ68svThjTVj6jhyq9XGxlY2xDrLVagmXOUhUV57xQbC3EnOnxyEdNbA== X-Received: by 2002:a1c:544f:: with SMTP id p15mr30929023wmi.84.1593700822091; Thu, 02 Jul 2020 07:40:22 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id v3sm10928701wrq.57.2020.07.02.07.40.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 07:40:21 -0700 (PDT) Subject: Re: Building today's snapshot of GDB with MinGW To: Simon Marchi , Eli Zaretskii 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> Cc: tromey@adacore.com, brobecker@adacore.com, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <76a315f9-ed60-93b4-10ab-95bc3bc8ae64@palves.net> Date: Thu, 2 Jul 2020 15:40:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9876615e-ab54-9fc4-4892-f855901e951e@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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 14:40:25 -0000 On 7/2/20 3:25 PM, Simon Marchi via Gdb-patches 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 ;; > 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). See: https://sourceware.org/legacy-ml/gdb-patches/2009-04/msg00420.html > 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. >