Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM?

[Simon Marchi via Gdb <gdb@sourceware.org>]

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