This is patch is in regard to issues discussed here:
https://www.mail-archive.com/gem5-dev@gem5.org/msg39122.html
The aim of this patch is to set a potential fix, and to give more
valuable debugging information.
It is not known why Kokoro sometimes fails, but it may be due to the
Docker service not starting fully prior to execution of the tests
within a Docker container. As such a 2 second sleep has been added
between starting the Docker service and running the tests.
The pulling of the docker images has been separated out to run at the
start of testing. This should help us determine whether the issue lays
with the pulling of an image or the running of a container.
The bash debug flag `-x` has been set so the expansion of each line can
be determined upon the event of a failure.
This patch will be reverted if it is found to not solve the issue.
Change-Id: I0d2dd8a080f64296e55f4b6de9a036d94d19c8ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45999
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This adds 64-bit statically linked big and little endian
binaries for the hello test program.
It should be noted that all possible combinations of ABI
version and endianness are possible for 64-bit binaries.
However, standard toolchains always use ELF ABI v1 for
big endian and ELF ABI v2 for little endian binaries.
Change-Id: I2dca7eaa2b04a7b68b117ada799d4c3bb69368be
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40951
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Commit a440108cc ("tests: Add Makefiles for hello")
introduced Makefiles for building the hello test binary
for ARM and x86 using dockcross. Since dockcross also
provides an image with a 64-bit little endian toolchain
for Power, this adds a Makefile for building the hello
binary.
As of this moment, 64-bit little endian (ppc64le) is the
prevalent variant supported by most distributions. Hence,
we are currently limited to only building the binary for
this variant.
Change-Id: Ic20322ca33c69634d9f17d30b29e522cc35742fb
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40949
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Previously the pyunit tests needed run in the gem5 root, this change
allows them to run as part of the quick TestLib tests (thereby having
them run as part of the presubmit checks). This runs all the TestLib
tests as a single test using the NULL gem5 binary.
`tests/run_pyunit.py` has been updated to only parse files with the
`pyunit` prefix in their filname. As such `pyunit/util/test_convert.py`
has been renamed `pyunit/util/pyunit_convert_check.py`. The word `test`
has been removed entirely as to not clash with the testlib tests as run
by `tests/main.py`.
Example usage:
```
./main.py run --uid SuiteUID:tests/pyunit/test_run.py:pyunit-tests-NULL-x86_64-opt
```
Discussed briefly in email thread:
https://www.mail-archive.com/gem5-dev@gem5.org/msg38563.html
Change-Id: Id566d44fcb5d8c599eb1a90bca56793158a201e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44625
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
dev/ has unit tests, but they are not run when
using the NULL ISA. The currently existing tests
are not ISA-specific, so the tests were set to
be run at an ARM environment.
As of now this is enough, but when ISA-specific
tests from ISAs other than ARM are added one will
need to change to cover them too.
Change-Id: I18df0141d415286325463afa759459b04ac8a92f
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44367
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
We have seen cases where the primary CPU was not able to bootstrap the
secondary CPUs in multicore tests (dual). The Linux booting process
"quietly" gives up (no panic) and it completes the booting without
bringing up the seondary CPU(s). This makes the dual test useless as it
is supposed to test SMP setups.
By adding a MatchFileRegex verifier, we make sure we are able to catch
these cases, correctly raising an error if not all CPUs are available.
We do this by inspecting the kernel log for the following print:
"CPU1: Booted secondary processor"
There are probably more resilient alternatives to a regex based check,
but those require a less minimal rootfs (the current
m5_exit.squashfs.arm64 FS has a single /sbin/init binary executing a
simple m5 exit operation)
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I37e0882967443449d5fedfe3963bd25528a030f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44446
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This vestigial device provides a thin layer of indirection between
devices and the CPUs in a system. It's basically a collection of helper
functions, but since it's a SimObject it needs to be instantiated in
python and added to configurations.
Change-Id: I029d2314ae0bb890678e1e68dafcdab4bfe49beb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43347
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is adding an extra parameter to the Ruby.create_system
function. The idea is to remove any assumption about cpu configuration
in the ruby scripts.
At the moment the scripts are assuming a flat list of cpu assigned
to the system object. Unfortunately this is not standardized, as
some systems might empoloy a different layout of cpus, like grouping
them in cluster objects.
With this patch we are allowing client scripts to provide the cpu list
as an extra argument
This has the extra benefit of removing the indexing hack
if len(system.cpu) == 1:
which was present in most scripts
Change-Id: Ibc06b920273cde4f7c394d61c0ca664a7143cd27
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43287
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
If supported this will compress the debug information in object files,
libraries, and binaries. This decreases the size of the build/ARM
directory from 11GB to 7.2GB.
Because the benefit of this mechanism depends on the performance and
capacity of the build machine's storage, it can be disabled with the
--no-compress-debug scons flag. For instance if your storage is very
fast, writing out a larger binary may take less time than compressing
that same number of bytes, plus the time to write out the smaller
file.
This feature seems to make our presubmit test machine run out of memory
when trying to build gem5, and so is disabled in the testing scripts.
Change-Id: I71919062d23742b7658918b0fa9c4d91d0521fbf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40715
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The 32-bit POWER reference test binary was removed in c1ebdf66f
(as a nasty surprise for POWER users).
The remaining platforms split between two approaches:
MIPS rebuilds "hello" from source.
This fails for two reasons:
1) The trivial reason is that on POWER make abends due to no makefile.
2) The more fundamental reason is that gem5 is not completely bug-free
(especially the Decoder on POWER in this case), therefore regression
testing is only possible if we have not just some hello program, but
a very particular bit sequence to serve as an immutable reference.
ARM and X86 follow the reference-bit-sequence approach. POWER will
be consistent with same. Including the sha1 for hello32,
77b27b67393311546e768b5ff35202490bad71aa, as a simple immutability
assurance. I have also renamed hello to hello32 in anticipation to
merge Sandipan's e52dbcb.
Change-Id: I77ef31349c9e50b987c6f58bb23324844527366d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40635
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-by: Pratik Sampat <pratik.r.sampat@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We compile GCN3_X86 for the 'quick' tests, as a substitute for X86. We
compile X86 as part of our nightly tests, along with the running of the
'long' tests. This leads to a needless duplicate compilation of the X86
isa during our nightly tests. Therefore, this commit removes GCN3_X86
for the 'long' tests (only the x86 boot tests are affected).
Change-Id: Ifd8aaf0e7b8178c588ace33b27671d4ba9b353ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40415
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch updates Ruby configuration scripts to use the functions
defined in the RubySequencer python object to connect to cpu ports.
Only the protocol-agnostic scripts were updated. Scripts that assume
a specific protocol (e.g. configs/example/apu_se.py, gpu tests, etc)
and scripts in which the obj connected to the RubySequencer is not a
BaseCPU (e.g. the tests scripts) were not changed as they require a
non-standard port wireup.
Change-Id: I1e931ff0fc93f393cb36fbb8769ea4b48e1a1e86
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31418
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Inside the code of cloneFunc(…) //syscall_emul.hh
cp->initState(); //line 1483
p->clone(tc, ctc, cp, flags); //line 1484
…
ctc->clearArchRegs(); //line 1503
OS::archClone(flags, p, cp, tc, ctc, newStack, tlsPtr); //line 1505
…
At line 1483, initState() is called and the activateContext() of the
corresponding MinorCPU is eventually called. The actual architecture
clone happens at line 1505 where PC of the new thread could have a
correct value.
In the existing implementation of MinorCPU::activateContext(ThreadID
thread_id), the below line 275 is called
pipeline->wakeupFetch(thread_id);
to start fetching instruction with current value of PC, which is 0x0,
leading to panic “Page table fault when accessing virtual address 0”.
This is because the OS::archClone() is not yet called. So, the below bug
fix handles the wakeup fetch for a thread for two scenarios:
...
if (!threads[thread_id]->getUseForClone())
{ //the thread is not cloned
pipeline->wakeupFetch(thread_id);
} else {//the thread from clone
if (fetchEventWrapper != NULL)
delete fetchEventWrapper;
fetchEventWrapper = new EventFunctionWrapper([this, thread_id]
{pipeline->wakeupFetch(thread_id);}, "wakeupFetch");
schedule(*fetchEventWrapper, clockEdge(Cycles(0)));
}
...
If a thread is not cloned, pipeline->wakeupFetch() is called
immediately.
For the cloned thread, the above bug fix delays the execution of
pipeline->wakeupFetch()
after the OS::archClone is done. ThreadContext::getUseForClone() return
true if a thread is cloned.
A member variable fetchEventWrapper is added to MinorCPU class for
delayed fetch event.
A member variable useForClone and its corresponding get/set methods are
added to ThreadContext class. This approach allows future reuse of this
useForClone variable by other CPU models if needed and also avoid lots
of changes resulted by modifying parameters of activateContext () and
activate() which are defined as override.
Inside the syscall cloneFunc, the useForClone member of a ThreadContext
object is set via its set method right before Process's initState() is
called, shown as below.
ctc->setUseForClone(true);
cp->initState();
p->clone(tc, ctc, cp, flags);
A few previously failed RISC-V ASM tests have been open in tests.py file
after the bug fix works.
JIRA issue: https://gem5.atlassian.net/browse/GEM5-374
Change-Id: Ibffe46522e2617443d29f49df180692c54830f14
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37315
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
In efforts to reduce storage costs and download times, the images hosted
by us have been gzipped. The TestLib framework has therefore been
extended to decompress gzipped files after download.
The x86-boot-tests are, at present, the only tests which use the gem5
images. These tests have been updated to download the gzipped image.
Change-Id: I6b2dbe9472a604148834820db8ea70e91e94376f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35257
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Occasionally gem5's stdout/stderr, when run within the TestLib
framework, will be shuffled. This is resolved by flushing the
stdout/stderr buffer before and after simulation.
In addition to this, the verifier.py has been improved to remove
boilerplate gem5 code from the stdout comparison.
Change-Id: I04c8f9cee4475b8eab2f1ba9bb76bfa3cfcca6ec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34995
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The log_call helper is now accepting a time parameter (dictionary). If
the param is not None, the function will fill the timing indications
(user and system time) for the TestCase.
There are some TestCases whose user time is not of our interest; for
example we don't really care about the cpu time of a stdout diff
(MatchStdout tests). In those cases the resulting cpu time in the
generated JUnit file (results.xml) will be 0.
JIRA: https://gem5.atlassian.net/browse/GEM5-548
Change-Id: I53c1b59f8ad93900aeac06197e39189c00a9053c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32653
Tested-by: kokoro <noreply+kokoro@google.com>
The workload object is still optional for the sake of compatibility,
even though it probably shouldn't be in the long term. If a simulation
is just a collection of components with nothing in particular running on
it, for instance driven by a traffic generator, should it even have a
System object in the first place?
Change-Id: I8bcda72bdfa3730248226fb62f0bba9a83243d95
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33278
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
