From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id b5RIFS4FLmmiMw0AWB0awg (envelope-from ) for ; Mon, 01 Dec 2025 16:14:22 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=l3aD869N; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4681F1E0B3; Mon, 01 Dec 2025 16:14:22 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no autolearn_force=no version=4.0.1 Received: from sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 9F1341E048 for ; Mon, 01 Dec 2025 16:14:21 -0500 (EST) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2CE5548FD844 for ; Mon, 1 Dec 2025 21:14:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2CE5548FD844 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1764623661; bh=BcfRyXQGG3lfBwSmTMT5vvtHUtgGVjbpzybLqedekso=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=l3aD869Na8yDQrfIqiQlwirgRzbmT6Zewmdu1v7tpO3qWWcTNyO8H4KsVe8y3+FiO 7LIgb6ASwUbL0h6Z7TQgvV4IjN0KL1l931L7FvqSuvlYOefQ/e8ZMLiBx4E6iT9fmj bZMLITJNa5/rpyLgl1s75Jicp2ZqCDjJBraoznvA= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 2DF6248FDB2D for ; Mon, 1 Dec 2025 21:13:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DF6248FDB2D ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2DF6248FDB2D ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764623626; cv=none; b=wN1yPAQLQXt0j+SURg4BwQfcv+9UEG5iQXcNDuJYToqW3+IcYENNK7MvmTsYiP8KHDcUZOJUMQS9lSmxrLKE8ZcjvrzpXx2sLUHvxWF8GUG4waNcFSsEZIjNhSHXROTEeTCCD6cANYrWBS5JLzjgy6U2uVW9JWRZ7H/LUsz2rRU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764623626; c=relaxed/simple; bh=lCKE0Gik0O81p8F1k86FOozEgQDRNeOHYToqmIcVZVs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=VeSnA3j3d64XyKnruonEUrQeHhg7WZH6vBopRJiHuqWlFUOEoKzxlXDt8oq3w5oTlNHHvbqe4KKRR0GtCxky7O0Cb4JV3AAbHgLk1qZT2xSLjZu7NGLvm23zZsQhnSIwu0MxZdAkq313InGv4XtXpeW3DQ8W7JxXk56s+Uucpyk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2DF6248FDB2D Received: by simark.ca (Postfix) id A7EE51E048; Mon, 01 Dec 2025 16:13:45 -0500 (EST) Message-ID: <41e77752-34ad-463a-99a1-9c35b7220b16@simark.ca> Date: Mon, 1 Dec 2025 16:13:45 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM? To: psmith@gnu.org, gdb@sourceware.org References: <2f8e6564c0110db9be7ed9b5ab78ee5c9349ca0a.camel@gnu.org> <3188e560-bf2b-4b31-9347-9ed870fb3eb3@simark.ca> Content-Language: en-US In-Reply-To: <3188e560-bf2b-4b31-9347-9ed870fb3eb3@simark.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2025-12-01 15:19, Simon Marchi via Gdb wrote: > > > On 2025-12-01 10:36, Paul Smith via Gdb wrote: >> If I build an x86_64 GDB binary that has support for debugging ARM core >> files, it works fine. The build is invoked (on x86_64) like: >> >> $ ../gdb-6.3/configure ... --enable-targets=aarch64-linux-gnu >> ... >> $ make -j$(nproc) >> >> There's no problem and the resulting GDB works both for native x86_64 >> cores and ARM cores. >> >> But, if I try to build an aarch64 GDB (on an ARM system) that has >> support for debugging x86_64 core files, the build fails like this: >> >> $ ../gdb-6.3/configure ... --enable-targets=x86_64-linux-gnu >> ... >> $ make -j$(nprocs) >> ... >> make[2]: *** No rule to make target '../sim/aarch64/libsim.a', needed by 'gdb'. Stop. >> >> If I use the same configure arguments but omitting --enable-targets >> then I get a correctly built GDB that will work on ARM. >> >> Comparing sim/config.log from the ARM build without --enable-targets >> (which works) versus the failing one, shows nothing too interesting; I >> get the same messages etc. The only consequential difference is that >> in the working version (no extra enabled targets) I see: >> >> SIM_ENABLE_ARCH_aarch64_FALSE='#' >> SIM_ENABLE_ARCH_aarch64_TRUE='' >> >> while in the failing version (with x86_64 enabled target) I see: >> >> SIM_ENABLE_ARCH_aarch64_FALSE='' >> SIM_ENABLE_ARCH_aarch64_TRUE='#' >> >> Which could have been guessed from the error message I suppose :). >> >> >> Anyone have any further advice? I guess the next step would be to run >> configure with sh -x and see if I can deduce where it gets confused >> (assuming this is a supported configuration). > > I don't know why using `--enable-targets=...` makes the sim configure > script decide not to build the simulator for aarch64. > `--enable-targets` enables a target on top of the default one (in this > case aarch64). So if the simulator is built and linked when not using > `--enable-targets=...`, then I think it would make sense to do the same > when using `--enable-targets...`. > > If your goal is to get something working right now, you can try > --disable-sim, or use --target=x86_64-linux-gnu, which will produce a > GDB that runs on aarch64 but only knows about debugging x86_64 targets > and cores. > > Simon I think I found the problem: https://gitlab.com/gnutools/binutils-gdb/-/blob/887bcaf98ea8e1ef76f6dd429b01b5258a782172/sim/configure.ac#L73 We essentially do: for targ in aarch64-unknown-linux-gnu x86_64-linux-gnu; do // try to match $targ against all known targets done During the "aarch64" iteration, we get a match, so we set sim_enable_arch_aarch64 to true and call AM_CONDITIONAL to define SIM_ENABLE_ARCH_AARCH64 to true. During the x86_64 iteration, sim_enable_arch_aarch64 is set to false (first line of macro SIM_TARGET), and because it's not a match, it remains false, and we call AM_CONDITIONAL again to define SIM_ENABLE_ARCH_AARCH64, but this time with false (I guess it overrides the previous call). The bug is that if an iteration has enabled the sim for a given arch, a later iteration should not undo that. Here's a possible fix (you'll need to re-generate the configure file): diff --git a/sim/configure.ac b/sim/configure.ac index a9e2528c967..1460e3726e4 100644 --- a/sim/configure.ac +++ b/sim/configure.ac @@ -70,7 +70,7 @@ dnl Enable a particular arch subdir. dnl arg[1] is the matching target triple. dnl arg[2] is the arch subdir name. m4_define([SIM_TARGET], [dnl - sim_enable_arch_$2=false + ${sim_enable_arch_$2:=false} case "${targ}" in all|$1) if test "${targ}" = "${target}"; then Another fix could be to skip the bulk of SIM_TARGET is sim_enable_arch_$2 is already set and true. Feel free to make a proper patch out of it and send it for review. Simon