configure: Re-disable building cross-gdbserver

On 2/11/20 9:01 PM, Maciej W. Rozycki wrote:
> On Tue, 11 Feb 2020, Tom Tromey wrote:
> 
>> Maciej> Correct fallout from commit 919adfe84092 ("Move gdbserver to top level") 
>> Maciej> and revert to not building `gdbserver' in a cross-configuration, that is 
>> Maciej> where host != target, matching the documented behaviour.  We have no way 
>> Maciej> to support non-native `gdbserver', and native `gdbserver' is usually of 
>> Maciej> no use with cross-GDB of the chosen host.
>>
>> Pedro had a different way to do this, that keeps the decision under
>> gdbserver's control:
>>
>> https://sourceware.org/ml/gdb-patches/2020-02/msg00383.html
> 
>  That's actually quite similar to what I considered first, before I 
> changed my mind.  Whatever.

Doing it in gdbserver/ has the advantage that it stays under gdbserver's
control, so it doesn't need syncing code with the gcc tree.  I know of at
least one off-tree port that uses gdbserver in a host != target scenario,
so I imagine that this condition will evolve over time.

Also, this way, changes in this area don't require running autoconf to
regenerate configure.

I'm not seeing any downside.

> 
>  However I would expect `exit' not to be what we want in a sourced script 
> (I did this differently; see below).

Good point, somehow did not think of that.
It worked in my patch because we source the script in a sub-shell.
But it's clearer/better to not rely on that.

>  
>  case "${host}" in
> +  ${target})
> +			gdbserver_host=${host}
> +			;;
> +  *)
> +			gdbserver_host=NONE
> +			;;
if/else reads more to-the-point to me, so I tweaked it that
way, and merged it in (to binutils-gdb), like below.

I'm sorry for not noticing your earlier patch.

From f20e3e823d56e54ffe56792ea6a2fe947c2dec0d Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro@wdc.com>
Date: Wed, 12 Feb 2020 13:50:30 +0000
Subject: [PATCH] Disable gdbserver on host != target configurations

Correct fallout from commit 919adfe84092 ("Move gdbserver to top level")
and revert to not building `gdbserver' in a cross-configuration, that is
where host != target, matching the documented behaviour.  We have no way
to support non-native `gdbserver', and native `gdbserver' is usually of
no use with cross-GDB of the chosen host.

gdbserver/ChangeLog:
2020-02-12  Maciej W. Rozycki <macro@wdc.com>
	    Pedro Alves  <palves@redhat.com>

	Skip building gdbserver in a cross-configuration.
	* configure.srv: Set $gdbserver_host depending on whether $target
	is $host.  Use $gdbserver_host instead of $host.
---
 gdbserver/ChangeLog     |  7 +++++++
 gdbserver/configure.srv | 11 +++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)


base-commit: 38de8abe21fe17c31888094bd860a84f88cb5749

On Wed, 12 Feb 2020, Pedro Alves wrote:

> >  That's actually quite similar to what I considered first, before I 
> > changed my mind.  Whatever.
> 
> Doing it in gdbserver/ has the advantage that it stays under gdbserver's
> control, so it doesn't need syncing code with the gcc tree.  I know of at
> least one off-tree port that uses gdbserver in a host != target scenario,
> so I imagine that this condition will evolve over time.

 Sure, that makes sense to me.

> >  case "${host}" in
> > +  ${target})
> > +			gdbserver_host=${host}
> > +			;;
> > +  *)
> > +			gdbserver_host=NONE
> > +			;;
> if/else reads more to-the-point to me, so I tweaked it that
> way, and merged it in (to binutils-gdb), like below.

 Great, thanks for handling this!

> I'm sorry for not noticing your earlier patch.

 No worries, I'm glad we've got this sorted.

  Maciej