[PATCH 1/4] native-gdbserver: Clear isremote flag in board info

[Simon Marchi <simon dot marchi at polymtl dot ca>]

From: Simon Marchi <simon.marchi@ericsson.com>

This patch clears the "isremote" flag in the native-gdbserver board.
The goal is to make is similar to the native-extended-gdbserver board,
and I believe that's the (technically) correct thing to do.

IIUC, DejaGnu automatically considers boards remote if their names don't
match the local hostname.  That means that native-gdbserver and
native-extended-gdbserver are considered remote by default by DejaGnu,
even though they run on the build system.  native-extended-gdbserver,
however, overrides its isremote flag to force it to be not remote.  So
we are in that weird state where native-gdbserver is considered remote,
and native-extended-gdbserver is considered not remote.

There seems to be some confusion globally in the testsuite about what's
native and what's not, what's remote and what's not.  It's probably
because of the overlap in vocabulary between DejaGnu and GDB.

>From a DejaGnu point of view:

 - native: the host or target board is considered native if the its
   triplet is the same as the build system's triplet,
 - remote: the host or target board is considered remote if it's running
   on a different machine, and thus require ssh, for example, to run
   commands, versus simply running commands directly.

Note that native and remote are not mutually exclusive, as you can have
a remote machine that has the same triplet as the build machine.

>From a GDB point of view:

 - target: the abstraction layer used to debug, can be native or remote.
 - native: target used when GDB uses directly system calls such as
   ptrace to interact with processes on the same system its running on,
 - remote: target used when GDB speaks the Remote Protocol language with
   another program (which can be on the same machine or not).

Note that native and remote are mutually exclusive, as GDB can only have
one of them loaded at a specific time.

That means that there are cases where the DejaGnu target is not remote,
but the GDB target is (e.g. running gdbserver on the same machine).  You
can also have a remote DejaGnu target, but a native GDB target (e.g.
cross-compiling on x86 a GDB that runs on ARM and running the testsuite
with a remote ARM host).

Because of this confution, a lot of tests in the testsuite don't check
for the right kind of target remote.  For example, some use [is_remote
target] (which checks whether the DejaGnu target is remote), when what
they really want to know is whether GDB is using its remote target (e.g.
because feature X is only available when GDB debugs natively).  Those
should use [gdb_is_target_remote] instead.

Another kind of tests checking the wrong thing is when they want to know
whether the current GDB target is able to, for example, attach a
process.  Some tests use [is_remote target] for this, since,
conveniently, native-extended-gdbserver is considered not remote by
DejaGnu and can attach, while native-gdbserver is considered remote and
can't attach.  What they ought to check is (I think, correct me if I'm
wrong) $use_gdb_stub.  That variable indicates whether the remote GDB
target we are speaking to has the ability to run, attach/detach, etc.
It is set for native-gdbserver and unset for native-extended-gdbserver.
Perhaps this could be done differently, but that's how it's done
currently.

So, flipping isremote off for native-gdbserver changes some test
results, breaking some and enabling some that were previously skipped.
I believe it means that those tests are checking the wrong thing in some
way, and should be improved.

I have started to fix some of them, but I can't do all of them at once.
Also, some of them require careful analysis/discussion.  I'd still like
to submit this patch right now anyway, since I don't want to spend
countless hours fixing everything and then be told that my approach is
wrong... I'd like to be told right away, if that's the case :).  So, I
have included a few examples of fixed tests in the following patches,
but it's by no means comprehensive.

Here's a diff of the results before and after this patch, when testing
with native-gdbserver, so you can have an idea of what's affected:

  http://pastebin.com/NRRJMQjQ

gdb/testsuite/ChangeLog:

	* boards/native-gdbserver.exp: Clear board_info isremote flag.
	(${board}_spawn): Remove.
	(${board}_exec): Remove.
---
 gdb/testsuite/boards/native-gdbserver.exp | 24 ++----------------------
 1 file changed, 2 insertions(+), 22 deletions(-)

diff --git a/gdb/testsuite/boards/native-gdbserver.exp b/gdb/testsuite/boards/native-gdbserver.exp
index fb2c7b6..357ac4f 100644
--- a/gdb/testsuite/boards/native-gdbserver.exp
+++ b/gdb/testsuite/boards/native-gdbserver.exp
@@ -36,26 +36,6 @@ set_board_info exit_is_reliable 1
 # We will be using the standard GDB remote protocol.
 set_board_info gdb_protocol "remote"
 
-proc ${board}_spawn { board cmd } {
-    global board_info
+set baseboard [lindex [split $board "/"] 0]
+set board_info($baseboard,isremote) 0
 
-    set baseboard [lindex [split $board "/"] 0]
-
-    set board_info($baseboard,isremote) 0
-    set result [remote_spawn $board $cmd]
-    set board_info($baseboard,isremote) 1
-
-    return $result
-}
-
-proc ${board}_exec { hostname program args } {
-    global board_info
-
-    set baseboard [lindex [split $hostname "/"] 0]
-
-    set board_info($baseboard,isremote) 0
-    set result [remote_exec $hostname $program $args]
-    set board_info($baseboard,isremote) 1
-
-    return $result
-}
-- 
2.8.0