Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* GDB 16.3: is it possible to cross-debug an x64 core from ARM?
@ 2025-12-01 15:36 Paul Smith via Gdb
  2025-12-01 19:53 ` Tom Tromey
  2025-12-01 20:19 ` Simon Marchi via Gdb
  0 siblings, 2 replies; 9+ messages in thread
From: Paul Smith via Gdb @ 2025-12-01 15:36 UTC (permalink / raw)
  To: gdb

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).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM?
  2025-12-01 15:36 GDB 16.3: is it possible to cross-debug an x64 core from ARM? Paul Smith via Gdb
@ 2025-12-01 19:53 ` Tom Tromey
  2025-12-01 20:19 ` Simon Marchi via Gdb
  1 sibling, 0 replies; 9+ messages in thread
From: Tom Tromey @ 2025-12-01 19:53 UTC (permalink / raw)
  To: Paul Smith via Gdb; +Cc: psmith

>>>>> "Paul" == Paul Smith via Gdb <gdb@sourceware.org> writes:

Paul> But, if I try to build an aarch64 GDB (on an ARM system) that has
Paul> support for debugging x86_64 core files, the build fails like this:

Paul>   $ ../gdb-6.3/configure ... --enable-targets=x86_64-linux-gnu
Paul>     ...
Paul>   $ make -j$(nprocs)
Paul>     ...
Paul>   make[2]: *** No rule to make target '../sim/aarch64/libsim.a', needed by 'gdb'.  Stop.

Either the sim should be auto-disabled when it isn't available for the
port, or it should build and be linked in.  So one way or another this
is a bug.  Is the sim code built for you?

FWIW I normally use --enable-targets=all so I'm usually seeing all the
sims be built (though only one can be linked in).

A workaround for you would be to disable the sims, aka --disable-sim.
However it would be better to find out what's really gone wrong.

Tom

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM?
  2025-12-01 15:36 GDB 16.3: is it possible to cross-debug an x64 core from ARM? Paul Smith via Gdb
  2025-12-01 19:53 ` Tom Tromey
@ 2025-12-01 20:19 ` Simon Marchi via Gdb
  2025-12-01 21:13   ` Simon Marchi via Gdb
  1 sibling, 1 reply; 9+ messages in thread
From: Simon Marchi via Gdb @ 2025-12-01 20:19 UTC (permalink / raw)
  To: psmith, gdb



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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM?
  2025-12-01 20:19 ` Simon Marchi via Gdb
@ 2025-12-01 21:13   ` Simon Marchi via Gdb
  2025-12-03 13:13     ` Paul Smith via Gdb
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Marchi via Gdb @ 2025-12-01 21:13 UTC (permalink / raw)
  To: psmith, 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM?
  2025-12-01 21:13   ` Simon Marchi via Gdb
@ 2025-12-03 13:13     ` Paul Smith via Gdb
  2025-12-05 19:10       ` Luis via Gdb
  0 siblings, 1 reply; 9+ messages in thread
From: Paul Smith via Gdb @ 2025-12-03 13:13 UTC (permalink / raw)
  To: Simon Marchi, gdb

On Mon, 2025-12-01 at 16:13 -0500, Simon Marchi wrote:
> 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

Thanks, I was in the middle of looking at that when I got your email :)

I submitted a patch to fix this:
https://sourceware.org/pipermail/gdb-patches/2025-December/223119.html

I did it a different way than the simplest option, but that to me seems
safer and more reliable.  I tried to keep with the same style used in
other sh code in configure.ac.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM?
  2025-12-03 13:13     ` Paul Smith via Gdb
@ 2025-12-05 19:10       ` Luis via Gdb
  2025-12-05 22:40         ` Paul Smith via Gdb
  0 siblings, 1 reply; 9+ messages in thread
From: Luis via Gdb @ 2025-12-05 19:10 UTC (permalink / raw)
  To: psmith; +Cc: Simon Marchi, gdb

To be honest, the aarch64 sim is very outdated. I'm not sure why we still
carry it around.

On Wed, Dec 3, 2025, 13:14 Paul Smith via Gdb <gdb@sourceware.org> wrote:

> On Mon, 2025-12-01 at 16:13 -0500, Simon Marchi wrote:
> > 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
>
> Thanks, I was in the middle of looking at that when I got your email :)
>
> I submitted a patch to fix this:
> https://sourceware.org/pipermail/gdb-patches/2025-December/223119.html
>
> I did it a different way than the simplest option, but that to me seems
> safer and more reliable.  I tried to keep with the same style used in
> other sh code in configure.ac.
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM?
  2025-12-05 19:10       ` Luis via Gdb
@ 2025-12-05 22:40         ` Paul Smith via Gdb
  2025-12-07 18:41           ` Luis via Gdb
  0 siblings, 1 reply; 9+ messages in thread
From: Paul Smith via Gdb @ 2025-12-05 22:40 UTC (permalink / raw)
  To: Luis; +Cc: gdb

On Fri, 2025-12-05 at 19:10 +0000, Luis wrote:
> To be honest, the aarch64 sim is very outdated. I'm not sure why we
> still carry it around.

Well, it's built if you configure GDB with --enable-targets holding
aarch64-linux-gnu, and if you don't use that configure option then you
can't cross-debug ARM cores on non-ARM systems.

If you're suggesting that it should be possible to cross-debug for ARM
without that sim, I can't speak to that.

Cheers!

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM?
  2025-12-05 22:40         ` Paul Smith via Gdb
@ 2025-12-07 18:41           ` Luis via Gdb
  2025-12-08 18:08             ` Paul Smith via Gdb
  0 siblings, 1 reply; 9+ messages in thread
From: Luis via Gdb @ 2025-12-07 18:41 UTC (permalink / raw)
  To: psmith; +Cc: gdb

On 05/12/2025 22:40, Paul Smith wrote:
> On Fri, 2025-12-05 at 19:10 +0000, Luis wrote:
>> To be honest, the aarch64 sim is very outdated. I'm not sure why we
>> still carry it around.
> 
> Well, it's built if you configure GDB with --enable-targets holding
> aarch64-linux-gnu, and if you don't use that configure option then you
> can't cross-debug ARM cores on non-ARM systems.

I usually build gdb with --enable-targets=all to get all the ports. I 
also disable all the sims with what Tom suggested (--disable-sim).

> 
> If you're suggesting that it should be possible to cross-debug for ARM
> without that sim, I can't speak to that.

Cross-debugging should work without building the simulators, and I´d 
recommend doing that so you don´t build more than required.

What I was suggesting (not specifically to you, but as an idea) is that 
we (as a project) ought to think about removing the aarch64 simulator as 
it is very stale.

> 
> Cheers!


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: GDB 16.3: is it possible to cross-debug an x64 core from ARM?
  2025-12-07 18:41           ` Luis via Gdb
@ 2025-12-08 18:08             ` Paul Smith via Gdb
  0 siblings, 0 replies; 9+ messages in thread
From: Paul Smith via Gdb @ 2025-12-08 18:08 UTC (permalink / raw)
  To: gdb

On Sun, 2025-12-07 at 18:41 +0000, Luis wrote:
> > If you're suggesting that it should be possible to cross-debug for
> > ARM without that sim, I can't speak to that.
> 
> Cross-debugging should work without building the simulators, and I´d 
> recommend doing that so you don´t build more than required.

Oh OK.  I didn't realize that the sim content wasn't used for cross-
debugging.  I don't know what that directory does but it seemed logical
to assume "simulator" code would be related to cross-debugging.  Wrong
again! :)

Thx.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2025-12-08 18:09 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-01 15:36 GDB 16.3: is it possible to cross-debug an x64 core from ARM? Paul Smith via Gdb
2025-12-01 19:53 ` Tom Tromey
2025-12-01 20:19 ` Simon Marchi via Gdb
2025-12-01 21:13   ` Simon Marchi via Gdb
2025-12-03 13:13     ` Paul Smith via Gdb
2025-12-05 19:10       ` Luis via Gdb
2025-12-05 22:40         ` Paul Smith via Gdb
2025-12-07 18:41           ` Luis via Gdb
2025-12-08 18:08             ` Paul Smith via Gdb

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox