This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[binutils-gdb] gdbserver-base.exp: Copy file to standard output directory in ${board}_download


https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8c4c4aeba6e32e3b7d0a4fbda4494b17883dd9c4

commit 8c4c4aeba6e32e3b7d0a4fbda4494b17883dd9c4
Author: Simon Marchi <simon.marchi@ericsson.com>
Date:   Wed Apr 13 10:15:40 2016 -0400

    gdbserver-base.exp: Copy file to standard output directory in ${board}_download
    
    gdbserver-base.exp is used as the base for both native-gdbserver.exp and
    native-extended-gdbserver.exp.  (Despite its name, it should really be
    considered as a "local-gdbserver-base", as it's not really appropriate to
    implement a remote gdbserver board.)
    
    Currently, the _download procedure is implemented as a no-op (it returns
    the source file path).  Because of the SONAME change, The fast
    tracepoint tests now require the executable and the IPA
    (libinproctrace.so) to be located in the same directory (see [1]).  When
    using the native-gdbserver board, because _download returns the original
    file path, the executable does not end up in the same directory as the
    library, and it fails to execute.
    
    In more general terms, with the recent changes, the testsuite now
    assumes that when it does
    
      ${board}_download <source path 1> <destination path 1>
      ${board}_download <source path 2> <destination path 2>
    
    where the destination paths are relative (generally just the file name),
    both files will end up in the same base directory.  That assumption does
    not hold for the current implementation in gdbserver-base.exp.
    
    The proper fix would be to make native-gdbserver non-remote, so that
    gdb_remote_download would not call DejaGnu's remote_download (see [2]).
    We could then get rid of ${board}_download in gdbserver-base.exp.
    However, that will likely take some time to complete.  In the mean time,
    in order to make the fast tracepoint tests pass, we can simply copy the
    file to the standard output directory.  Basically, it just mimics what
    gdb_remote_download would do if the board wasn't flagged as remote.
    
    Note that I missed these failures originally because I had a
    libinproctrace.so in /usr/local/lib.  So, even though libinproctrace.so
    wasn't copied to the test output directory, it did find the one in
    /usr/local/lib.  It would be nice to find a way to protect against this,
    as it could easily happen again...
    
    Regtested with unix, native-gdbserver and native-extended-gdbserver, and
    didn't see anything notable, except the ftrace tests now passing for
    native-gdbserver.
    
    [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95
    [2] https://sourceware.org/ml/gdb-patches/2016-04/msg00112.html
    
    gdb/testsuite/ChangeLog:
    
    	* boards/gdbserver-base.exp (${board}_download): Copy source file to
    	standard output directory.

Diff:
---
 gdb/testsuite/ChangeLog                 | 5 +++++
 gdb/testsuite/boards/gdbserver-base.exp | 9 ++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index a1a4c04..ef3e66d 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2016-04-13  Simon Marchi  <simon.marchi@ericsson.com>
+
+	* boards/gdbserver-base.exp (${board}_download): Copy source file to
+	standard output directory.
+
 2016-04-13  Antoine Tremblay  <antoine.tremblay@ericsson.com>
 
 	* gdb.trace/trace-condition.exp (foreach): Fix emit_sub testcase.
diff --git a/gdb/testsuite/boards/gdbserver-base.exp b/gdb/testsuite/boards/gdbserver-base.exp
index b686204..02a9244 100644
--- a/gdb/testsuite/boards/gdbserver-base.exp
+++ b/gdb/testsuite/boards/gdbserver-base.exp
@@ -41,7 +41,14 @@ proc ${board}_file { dest op args } {
 }
 
 proc ${board}_download { board host dest } {
-    return $host
+    # We pass DEST in standard_output_file, regardless of whether it is absolute
+    # or relative, because we don't want the tests to be able to write outside
+    # their standard output directory.
+    set dest [standard_output_file $dest]
+
+    file copy -force $host $dest
+
+    return $dest
 }
 
 proc ${board}_upload {dest srcfile args} {


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]