This makes it easier to manage the java wrapper since there's only one
file. This change also splits up the command builder which builds the
java jar since we need to run one step which produces the .h, then a
second step to build the library, and then finally the step that
produces the jar. The first step is left as a command builder since the
scons Java builder still doesn't know about the -h option, but the
second step now uses the Jar builder.
Change-Id: I76e2e5e86bb3153f2ba69a75ad94cd4e065cd33d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28183
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Convert the native implementation from C to C++. Also expand the test to
cycle through the different call mechanisms and call "sum" using each
one. This test should primarily be run on a gem5 native CPU which will
support all call types.
To access a particular call type, get an instance of the gem5.Ops class
from the callTypes static map, using the name of the call type you want
as the key. If you just want whatever the default is, use the additional
key "default".
Change-Id: If4ef812c9746fbf974e54cc9fe515e2b581e9939
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28182
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
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 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>
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>
When compiling static objects, disable pie with the -no-pie linker flag.
This is necessary for x86, and doesn't seem to hurt anything for the
other variants.
When compiling shared objects, particularly the assembly files which
can't rely on the compiler to generate position independent code, define
M5OP_PIC so that the assembly code can configure itself correctly.
Change-Id: I80d1ea7a7704666027e74228036af5e0e4b9eac2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27218
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are currently specific to aarch64, but will be expanded to cover
all other versions of the utility as well.
The intention of these new files is to centralize the build mechanism
for the different versions of the utility so that they have consistent
features, mechanisms, and targets, and so that new features will
automatically be shared by all versions without having to be implemented
in each.
This also sets up a separate build directory which will keep the source
tree clean, and will (with some more development) make it possible to
build multiple versions of the m5 utility at the same time without them
running into each other.
Change-Id: I10018eef6beb4af30a8d3bbab8b82cabd2b3f22c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27213
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
