This is the mail archive of the gdb-patches@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]

Remote testsuite problem: invalid executable cache


Hello,

when running the test suite in remote mode against a gdbserver target,
the executable under test is built on the host using a cross-compiler
and then downloaded to the target before the test starts.

Apparently in an attempt to reduce test times across a slow download
connection, the gdbserver_download_current_prog skips that download
if it thinks the executable is already on the target (e.g. if a test
case restarts GDB on the same executable multiple times).

This case is detected by comparing file name and time stamp of the
executable under test against those values remembered from the last
executable that was downloaded.

This seems fine at first glance, but actually doesn't quite work:

- Some tests, in particular multiple gdb.python tests, re-compile
  the executable under test several times, reusing the same name.
  For example, py-value.exp recompiles the same source file first
  using the C compiler and then using the C++ compiler, and runs
  a couple of tests on each.

- The gdbserver_download_current_prog time stamp check uses Tcl
  [file mtime ...], which only provides a resolution of 1 second.
  If the test runs fast enough, the second rebuild of the executable
  might happen to carry the same time stamp as the first one.

- This may cause the test suite to erroneously skip copying the C++
  executable, and run the C++ tests on the C executable (which will
  usually fail since GDB on the host side does use the new binary,
  so that instruction addresses will not match up).

Some options to fix this problem might include:

- Rewrite the Pyhton tests to not overwrite the same exectuable
  file (just use different names).

- Remove the cache.  (How bad it the download time problem, really?)

- Use better markers to identify unchanged executables (more precise
  timestamp?  checksum?).  Any hints on how to portably implement
  something along those lines in Tcl would be appreciated!

- Create some sort of hook that would allow "gdb_compile" to notify
  the executable cache that a file was just rebuilt.

Thoughts?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


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