From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: gdb-patches@sourceware.org
Subject: Remote testsuite problem: invalid executable cache
Date: Fri, 22 Jul 2011 15:22:00 -0000 [thread overview]
Message-ID: <201107221506.p6MF6ZwN024363@d06av02.portsmouth.uk.ibm.com> (raw)
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
next reply other threads:[~2011-07-22 15:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-22 15:22 Ulrich Weigand [this message]
2011-07-22 16:35 ` Jan Kratochvil
2011-07-22 16:53 ` Daniel Jacobowitz
2011-07-22 17:53 ` [rfc] " Ulrich Weigand
2011-07-22 18:40 ` Tom Tromey
2011-07-22 18:56 ` Ulrich Weigand
2011-07-24 18:04 ` Mark Kettenis
2011-07-25 18:33 ` Ulrich Weigand
2011-07-26 1:01 ` Stan Shebs
2011-07-26 17:31 ` [rfc] Avoid '+' in file names (Re: [rfc] Re: Remote testsuite problem: invalid executable cache) Ulrich Weigand
2011-07-26 18:20 ` Tom Tromey
2011-07-26 19:20 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201107221506.p6MF6ZwN024363@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox