Remote testsuite problem: invalid executable cache

Ulrich Weigand
2011-07-22T15:06:54Z

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,