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>
Decoder: gpu_decoder.hh and decoder.cc:
The decoder is defined in these files. The decoder
is implemented as a lookup table of function pointers
where each decode function will decode to a unique
ISA instruction, or do some sub-decoding to infer
the next decode function to call.
The format for each OP encoding is defined in the
header file.
Registers:
registers.[hh|cc] define the special registers and
operand selector values, which are used to map
operands to registers/special values. many
convenience functions are also provides to determine
the source/type of an operand, for example vector
vs. scalar, register operand vs. constant, etc.
GPU ISA:
Some special GPU ISA state is maintained in gpu_isa.hh
and isa.cc. This class is used to hold some special
registers and values that can be used as operands
by ISA instructions. Eventually more ISA-specific
state should be moved here, and out of the WF class.
Vector Operands:
The operands for GCN3 instructions are defined in
operand.hh. This file defines both scalar and
vector operands wth GCN3 specific semantics. The
vector operand class is desgned around the generic
vec_reg.hh that is already present in gem5.
Instructions:
The GCN3 instructions are defined and implemented
throughout gpu_static_inst.[hh|cc], instructions.[hh|cc],
op_encodings.[hh|cc], and inst_util.hh. GCN3 instructions
all fall under one of the OP encoding types; for example
scalar memory operands are of the type SMEM, vector
ALU instructions can be VOP3, VOP2, etc. The base code
common to all instructions of a certain OP encoding type
is implemented in the OP encodings files, which includes
operand information, disassembly methods, encoding type,
etc.
Each individual ISA isntruction is implemented as
a class object in instructions.[hh|cc] and are derived
from one of the OP encoding types. The instructions.cc
file is primarily for the execute() methods of each
individual instruction, and the header file provides
the class definition and a few instruction specific
API calls.
Note that these instruction classes were auto-generated
but not using the gem5 ISA description language. A
custom ISA description was used and that cannot be released
publicly, therefore we are providing them already in C++.
Change-Id: I14d2a02d6b87109f41341c8f50a69a2cca9f3d14
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28127
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.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>
It may be the case that each item M5OP_FOREACH iterates over should end
in a ',' and not a ';', for instance when putting each item into an
array or initializing a structure. If the caller still wants a ';', they
can add it into the definition of the M5OP macro.
Change-Id: Idd6538b0aad27df39658c3f749c6ff5e4fe55e6d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27237
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is a small additional layer on top of the initparam command and
just breaks the returned value into 12 bit chunks. It presumes that
there is some particular meaning to the default initparam value which
may or may not be true. It's not entirely clear what the 12 bit chunks
that this command returns are actually good for, and it's been around
long enough that there isn't really any good documentation about what
it's intended purpose was.
Change-Id: I21af0e0cf7501f47026a6dd31920d46cfccff167
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27232
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This change removes the responsibility for checking the number of
arguments and handing the default of no string back into init_param and
out of the function which packs strings into registers. It also renames
the function to more closely match its purpose, and rewrites it to be a
bit simpler and (IMHO) easier to follow.
Importantly, rather than doing a hand implemented strcpy which would
follow the endianness of the target/simulated platform, this change
makes this function pack the registers explicitly in little endian byte
order. This way on the consuming end in gem5, the initParam function
doesn't have to care what the guest endianness is, it can just translate
them from little endian to whatever the host endianness is (very likely
also little endian).
Change-Id: Ie9f79ecb8d4584c6e47a2793a31ccaa8c7c15986
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27229
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This command did not use any m5 ops, does the same thing as the
"taskset" command under Linux:
https://linux.die.net/man/1/taskset
and might even have introduced a build error if compiled for any other
OS since that would have left a trailing comma in the mainfuncs array.
While the last problem would be easy to correct, this is not related to
the purpose of this utility (giving access to m5 ops), and is redundant
with an existing standard utility provided with Linux.
Change-Id: Ie72b9310f5e6264f6035013f47ebe74a27464abb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27226
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Because I don't have a canonical toolchain to set SPARC's defaults to,
it will by default build for Linux instead of Solaris like it used to.
This will make it hard to test, but without a compiler there's not much
I can do.
This also coincidentally brings the SPARC version more in line with the
other variants which all target Linux.
Change-Id: Ie19217e988782da124306160920f40ef168840e4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27219
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
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>
This forces a test in the gcc Makefile to pick the right answer, where
its own check will not. Without this fix, installing libsanitizer fails
to build while installing the c++ headers because it can't find a
definition for PATH_MAX. Disabling building libsanitizer seems to work
around the problem, but other problems crop up later when using the
cross compiler, specifically when trying to build the googletest
library.
The chrome authors apparently ran into a similar problem when building
the native client tool chain as described in this bug:
https://bugs.chromium.org/p/nativeclient/issues/detail?id=3190
The CL which fixed the issue is here:
https://codereview.chromium.org/11462002/patch/1/2.
With a similar fix applied to build_cross_gcc.py, the cross compilers
build without issue, and are then able to build the googletest library
without issue.
Change-Id: Ia6869d3dc523cb0d964e82bb300f8b092693739b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27489
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
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>
When accessing m5_mem and building PIC code, we need to get the address
of m5_mem out of the global offset table, and then load the value from
there. If we try to load from m5_mem directly, the assembled code has a
relocation type the linker can't handle when building a shared object.
Change-Id: Ieb19c3d17c37ef810559ee24b68886b18ddcc869
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27212
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The header for the m5op entry points had moved. Also the names of the
entry points had been normalized to have a consistent structure. Neither
of those changes were ported to this file, making it no longer compile.
Change-Id: I890c0486bd19fe2692cce92983290e854dc87afa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27211
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Now that the annotation pseudo ops are removed, the subfunction is
always zero. It is no longer decoded within gem5 either. The format of
the pseudo op func/subfunc mechanism is unchanged for compatibility, but
the subfunc field will always be zero now.
Change-Id: I2167571577b6557d06aa26d8aecaca78797f5f59
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27205
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The python interpreter does some fancy things with memory which trips up
the lsan leak checker which comes along with asan. This file simply
tells lsan to ignore those leaks.
To use it when running a binary, set the LSAN_OPTIONS environment
variable to "suppressions=${PATH TO SUPPRESSIONS FILE}". To disable the
a report on the leaks that were suppressed, you should also set
"print_suppressions=0". Multiple options can be set by seperating them
with ":"s.
LSAN_OPTIONS=suppressions=util/lsan-suppressions:print_suppressions=0
Change-Id: Ie4d712c6b95f429e67361c41a9b545a8536f2511
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27124
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These files have settings for 32 and 64 bit ARM, MIPS, POWER, RISCV, and
SPARC. When used with the versions of toolchain components below, they
all generate working hello world binaries.
binutils-2.34
gcc-9.3.0
glibc-2.31
linux-5.5.9
gdb-9.1
The script was unable to install the c++ standard headers (step 8)
because a constant was not found when building one of the sanitizers. I
don't know exactly why this happens, but I suspect it's independent of
the build process.
Change-Id: I9f0068b77edf338ed63b95f007454c07651aa42a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26764
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Cross compilers are very useful when working with gem5. The how-to this
script is based on assumed the compiler was targeting linux, so there
isn't any support for compilers targeting other or no OS. That might be
possible to add in the future.
Change-Id: I2cb30ecbdd4c6292146ea64940348c24385046f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26763
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Change the guest ABI for x86 pseudo instructions to explictly write rax.
This is required because for some reason, the KVM CPU overwrites rax
after the KVM MMIO sets the value.
Note: This is hacky. It will only work for the current implementations
of x86 m5 ops which have their return value in RAX. A comment is added
to the m5ops file to make this clear.
Change-Id: I9466bf050b26db3650cfe3d23008e0f77fda8bc0
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25664
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
