[patch, testsuite] Run argv0-symlink.exp only on native target and local host.

[Sandra Loosemore <sandra at codesourcery dot com>]

I've been continuing to look into bogus test failures seen on remote 
Windows host, and it turns out gdb.base/argv0-symlink.exp is somewhat 
more broken than that.

This testcase was originally added for gdb/15415, a problem with the 
"run" command expanding symlinks in the name of the program being run. 
This test incorrectly uses pathnames on build to create symbolic links 
on host:

set status [remote_exec host "ln -sf ${testfile} [standard_output_file 
$filelink]"]

and expects the test program running on target to see those symbolic links:

    gdb_test {print argv[0]} "/$filelink\"" $test

I see there have been some attempts over the years to try to make this 
testcase not fail on bare-metal or gdbserver targets but nothing has 
really fixed the build/host/target filesystem confusion.  It's probably 
possible to do that somehow, but given that this was for a bug in the 
"run" command I'm not sure what the value is of attempting to run the 
test on targets that don't use "run".  (It wasn't a target-specific bug 
and GDB surely gets plenty of testing on targets that do use "run".)  So 
this patch just disables it on targets that are going to trip over the 
remote-host or remote-target problems unless there is something magic 
going on in the test environment (like, say, a shared network filesystem).

So, is this patch OK, or do we need to try harder to fix the testcase?

-Sandra

commit 145663b08d5a6610e5a90b807ce44ff2d41916d3
Author: Sandra Loosemore <sandra@codesourcery.com>
Date:   Sat Aug 17 13:44:17 2019 -0700

    Run argv0-symlink.exp only on native target and local host.
    
    This testcase was originally for PR gdb/15415, a problem with the
    "run" command expanding symlinks in the name of the program being run.
    It does not correctly distinguish between files on build, host, and target,
    and it is not clear if it would be testing anything useful in configurations
    where "run" is not being used.
    
    2019-08-17  Sandra Loosemore  <sandra@codesourcery.com>
    
    	gdb/testsuite/
    	* gdb.base/argv0-symlink.exp: Run only on native target
    	and local host.

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index edf7d17..b41d879 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2019-08-17  Sandra Loosemore  <sandra@codesourcery.com>
+
+	* gdb.base/argv0-symlink.exp: Run only on native target
+	and local host.
+
 2019-08-16  Tom de Vries  <tdevries@suse.de>
 
 	* gdb.base/compare-sections.exp ("after run to main"): Allow
diff --git a/gdb/testsuite/gdb.base/argv0-symlink.exp b/gdb/testsuite/gdb.base/argv0-symlink.exp
index cce6ca6..33301bd 100644
--- a/gdb/testsuite/gdb.base/argv0-symlink.exp
+++ b/gdb/testsuite/gdb.base/argv0-symlink.exp
@@ -13,6 +13,23 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
+# This testcase was originally for PR gdb/15415, a problem with the "run"
+# command expanding symlinks in the name of the program being run.
+# This test uses pathnames on build to create symbolic links on host and
+# expects the test program running on target to see those symbolic links.
+# Therefore, it can't work reliably on anything other than configurations 
+# where build/host/target are all the same.
+
+if { ![isnative] } {
+    unsupported "argv0-symlink.exp not supported on non-native target"
+    return -1
+}
+
+if { [is_remote host] } {
+    unsupported "argv0-symlink.exp not supported on remote host"
+    return -1
+}
+
 standard_testfile
 
 set has_argv0 [gdb_has_argv0]