These tests don't run reliably right now for a few reasons, including
problems with QEMU, and apparently inaccurate information from g++-s
--print-sysroot option.
This may be revisited in the future if those problems can be sorted out.
For now, avoid tripping up new people who won't know to (or how to) work
around those sorts of errors.
Change-Id: Ide42e6c6b27159ff146b8495ae568d1fd377f4f4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28179
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The java wrapper which provides access to the gem5 ops is implemented
using JNI in a .so file which needs to be loaded before the class can be
used. Rather than expecting the caller to do that, we can use a static
block in the class definition. We know that will be called at the right
time, and it's one less detail (arguably an implementation detail) that
the caller won't have to worry about.
Change-Id: I2b4b18ebb12030ea6f4e6463c6cd512afed74cfd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28177
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than use a top level package of jni which is generic, switch to a
top level package of "gem5". With that prefix, call the actual class
Ops, which is capitalized according to Java tradition and also
unambiguous given its package name.
Also move the java class definition and c JNI implementation into a java
subdir to keep it all together. The java related output will now be in
out/java for the same reason.
Change-Id: Ia0468d2edbcffe87a62022898f867ae391adc94c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28176
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Like gem5's own verbose scons flag, when this isn't provided, the output
is very brief and just shows what is being built and by what type of
process. When it is provided, the full command lines are printed.
This is less fancy than the version gem5 has, but I didn't want to
duplicate all that code. We should find a way to share that and other
functionality between different sets of scons scripts.
Change-Id: Id9973b57a1270ec8b364efd2aa67d49b0fb82a9d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27756
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This may be directly in the case of native tests, or through a user
level QEMU binary for non-native tests. scons is smart enough to expect
to be able to run native tests always, and non-native tests only if a
qemu binary has been found.
To tell scons to run tests in a particular category, you can use a
command of this form:
scons build/[category]/test/
where category is either an "abi" like sparc or x86, or "native" for
tests which don't do anything target specific and so can be run on the
host.
There will be two directories under .../tests, "bin" and "result". "bin"
is where the test binaries themselves will be built, and "result" is for
the results of running those binaries.
Change-Id: I6450ab4a97169f8a01292d946bfac18008b0430c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27752
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This verifies that the slightly more complex --addr command line option
behaves as expected.
Also, like the inst and semi call type unit tests, it will either
attempt to successfully perform a call to the "sum" m5 op if it's told
it's running under gem5, or it will attempt to catch itself failing to
run that command by using mprotect to block its access to the mmap-ed
region and then looks at the siginfo_t to make sure the attempted access
was to the right place, etc.
It also will attempt to verify the details of the mmap if possible by
looking up information about its own mmap-ings in /proc. If the file it
would expect to find the mappings in doesn't exist, it prints a warning
and gives up. If it does, it looks through it to find the line
corresponding to the m5 ops, and then checks some details of the mapping
like its size and its offset in the target file. The offset would
correspond to the physical address if using the real /dev/mem.
Change-Id: Icc14cd9ac02eae93c56f1f2aa78fd67d8540a2f2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27751
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This cleans up the mmap-ing. This is primarily used for testing since
the tests may end up mmap-ing the backing file many times, and we don't
want all those earlier mappings lying around.
This change also makes the original mmap-ing function close the file it
opens, since the man page for mmap explicitly says you can do that and
not lose the mapping. That means we don't have to keep track of the file
descriptor which corresponds to the mmap-ed file when we do the
unmapping, and it's slightly cleaner in general.
Change-Id: I90e3e755cebf3d03e2bf644adf8ef3e157236172
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27750
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This test does two things. First, it makes sure that the "inst" call
type detects that it's being requested in the command line arguments
correctly.
Second, it detects whether it's running in gem5 or not, really just
detecting an environment variable which tells it whether it is. If it
is, then it attempts to run the "sum" op which it expects to succeed and
give the right answer.
If not, it expects to get a SIGILL signal from the OS when it tries to
execute the otherwise illegal instruction. It sets up a signal handler
to catch it, and in that handler saves off information about what
happened. It then uses siglongjmp to return to sanity (before the
signal) and to examine what happened to see if the right instruction was
attempted.
It looks like, depending on the architecture, Linux will either set
si_code to ILL_ILLOPC (illegal opcode) or ILL_ILLOPN (illegal operand).
The later doesn't seem right since the entire instruction is illegal,
not just some operand, but it is what it is and we need to handle
either.
The test then calls a small function, abi_verify, which takes the
siginfo_t and does any abi specific verification. That includes
extracting fields from the instruction if the instruction trigger the
signal, or checking for architecture specific constants, etc.
Also, to centralize setting the macro which lets a call type know that
it's the default, the call types are now also responsible for setting up
their own tweaks to the environment.
Change-Id: I8710e39e20bd9c03b1375a2dccefb27bd6fe0c10
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27689
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When the command reports an error, it should then exit(2) and not just
return as if everything worked. When printing the number of bytes
written or the file being opened, it should write this non-error message
to cout, and not cerr.
Also used proper capitalization and punctuation in a couple messages.
Change-Id: I2c0d6592357965ed2eee8f090c8b3d530b354b9f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27627
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This feeds a fake file to the readfile command which is just a sequence
of incrementing 32 bit values. The incrementing values make sure that
the right region of the input file is being read at the right position,
and the relatively small size means there shouldn't be tons of zeroes
everywhere which can't be distinguished from each other.
Change-Id: I4286b1f92684f127c4885c29192c6c5244a61855
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27608
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This change adds the plumbing for and then implements a unit test for
the "sum" command. Despite the fact that this command is very simple,
there are a few things to verify.
1. That args are passed in the right positions.
2. That the number of arguments is checked correctly.
3. That the output to std::cerr is correct.
Change-Id: I71cd473b78fb710cac94df2d70c8d6dc76e5a037
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27566
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The library will be available for the abis so that they can test
their unique call mechanisms, and also the main/native environment for
testing shared components.
Build instructions for things that should be built natively, ie unit
tests for common components, should go in the new SConscript.native.
Change-Id: I4a84b2cf2165c92dfb1b6d903b18b45e4cba1352
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27559
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The name this function uses is now exposed as a global variable called
m5_mmap_dev which can be changed at run time.
This would be useful if using a non-standard location for /dev/mem, or
for testing where we might want to use a totally different device.
Change-Id: I5e7ac106c3e4e0555c99af2a7a0aca8171534451
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27556
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Create static methods to convert any string to an integer or to pack it
into an array of integers. Create non-static methdos named pop() to
pop() the first element and simultaneously convert it. If the conversion
fails, the argument is not popped.
Change-Id: I55d98b3971e7abb7b6206d06ec7fcf046e828d29
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27553
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Using mechanisms added in previous CLs, this change modifies the m5
utility so that it can use any of the back ends enabled and implemented
by each variant, defaulting to one particular implementation if not is
selected explicitly.
On x86, the default mechanism is the magic address. All other variants
default to the magic instruction since they don't have a well
established address to use or even in most cases an implementation to
use.
The ability to override the particular magic address the utility wants
to use (necessary on variants such as aarch64) will be added in a future
CL.
Change-Id: I5fc414740e30759e7dde719cddcc8d5d41f8cc74
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27242
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These make the calling code in m5.c a little bit more generic. Each call
type will have a function to check the arguments and see if that type is
being requested and/or has any additional options set in the arguments.
If so, those are processed, and argc and argv are adjusted.
Then another function returns the appropriate dispatch table to use for
that invocation scheme. This is behind a function instead of, for
instance, a global variable because it gives the call type a little bit
more control over what's happening, for instance if it would use
different implementations in slightly different circumstances.
Change-Id: I661cf202ec657466496767cbdf331fe27995ab26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27241
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
