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>
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>
Added -no-pie flag to link /util/m5 to support newer versions of GCC
that enable PIE by default. Tested for backwards compatibility with GCC
4.3, which, only warns for the unrecognized flag.
Change-Id: I4b6df593936346b9d3e2fe29a5d85dde78b7cc5e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17429
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
644e8cdf5e ("util: Move the m5ops.h file to a shared directory")
added include/ to the include path for m5 Makefiles, based on
$(PWD): $(PWD)/../../include.
Unfortunately, this breaks when using `make -C <path>`, as -C does
not move PWD accordingly. The fix is simply to remove $(PWD), as a
relative path is just fine here.
Change-Id: Ia046c29761363b6670e52c52a604c7e70a6a305a
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12844
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This module allows m5ops to be executed in Lua programs.
To compile it (in util/m5):
The following command generates Lua moduel, gem5OpLua.so.
make -f Makefile.<arch> gem5OpLua.so
To use it:
First, put gem5OpLua.so in Lua library search path.
Then, import the module and execute the m5op function.
Example usage, creating a checkpoint.
m5 = require("gem5OpLua")
m5.do_checkpoint(0, 0)
Change-Id: Icc18a1fb6c050afeb1cf4558fbdc724fb26a90e2
Reviewed-on: https://gem5-review.googlesource.com/6541
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Using m5ops for X86 in shared objects requires PIC for the m5ops.
Typically, the PIC version is used to make m5op interfaces to other
languages like python and lua.
Change-Id: I2463904c13ea8b839d0386d3c743d8dad1e1e6bc
Reviewed-on: https://gem5-review.googlesource.com/7261
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
When the writefile command is given one command line argument, it's treated
as the name of the file in the simulation and on the host. When there are two
arguments, the first is the filename in the simulation, and the second is the
name on the host.
Change-Id: I402925a9ff89665bee9910fb18b7f8b06b8f7d35
Reviewed-on: https://gem5-review.googlesource.com/4850
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
The header file with C declarations for m5ops is sometimes needed by
code outside of the util/m5 directory. Move this file to the shared
include directory and factor out flags to a generic asm header. Note
that applications that need to call m5ops still need to link with
libm5.a or implement their own trampolines.
Change-Id: I36a3f459ed71593e38b869dc2b1302c810f92276
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jose Marinho <jose.marinho@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/4265
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
The header file m5ops.h contains a list of constants that should be
shared between the simulator and utilities. Move this header file to a
new top-level directory for shared files and rename constants to make
them suitable for inclusion in the main simulator.
The structure of the shared include directory is as follows:
include/gem5: Files that can be included from C code.
include/gem5/asm: Files that can be included from assembly code.
asm/generic/: Files that aren't guest ISA specific
asm/${isa}/: Files that are guest ISA specific
Change-Id: I1aa511057bcaa80cc2d566109ff26581558c4a41
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jose Marinho <jose.marinho@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/4261
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
The style checker complains about line length and ordering for these
files. This fix should make these two files kosher.
Change-Id: I822a0518a98d9e379a543d2017e90c4e9666a58d
Reviewed-on: https://gem5-review.googlesource.com/3380
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Add support for memory-mapped m5ops in the aarch64 version of the m5
utility. To enable support for memory-mapped m5ops, compile the tool
with the define M5OP_ADDR set to the base of the m5op PA range.
Change-Id: I13e21e48536b9849bf4081411b66b2f350f7a8ac
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2966
The m5 tool has subcommands that writes a file to the simulated file
system. The implementation of this command currently doesn't check the
return value from write, which leads to compiler warnings and
potentially incorrect behavior. Add the necessary checks.
Change-Id: If558534d3245aa24cf15edf06bd0af4c6ba3908c
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2962
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
It seems like the m5 utility incorrectly called m5_loadsymbol instead
of m5_addsymbol. Judging by the signature of the loadsymbol command,
the expected behavior is to add a new symbol to gem5's symbol
table. This is behavior is implemented by m5_addsymbol.
Change-Id: I83b61c48d6f8d7b1e8b57d884dfca00481c83c3a
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2961
Reviewed-by: Gabe Black <gabeblack@google.com>
This patch adds the ability for an application to request dist-gem5 to begin/
end synchronization using an m5 op. When toggling on sync, all nodes agree
on the next sync point based on the maximum of all nodes' ticks. CPUs are
suspended until the sync point to avoid sending network messages until sync has
been enabled. Toggling off sync acts like a global execution barrier, where
all CPUs are disabled until every node reaches the toggle off point. This
avoids tricky situations such as one node hitting a toggle off followed by a
toggle on before the other nodes hit the first toggle off.
The m5ops assembly library contains a lot of repetitive code. This
changeset adds two macros, FOREACH_M5OP and FOREACH_M5_ANNOTATION, to
m5ops.h that simplify architecture-specific implementations. The ARM
and ARMv8 m5op implementations have been updated to use the new
macros.
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
This patch adds methods in KvmCPU model to handle KVM exits caused by syscall
instructions and page faults. These types of exits will be encountered if
KvmCPU is run in SE mode.
1) fixes a typo for clean target libgemOpJni.so -> libgem5OpJni.so
2) addes jni_gem5Op.h to clean since it is added during make
3) links the m5 utility statically since it won't work on some images otherwise
Note: AArch64 and AArch32 interworking is not supported. If you use an AArch64
kernel you are restricted to AArch64 user-mode binaries. This will be addressed
in a later patch.
Note: Virtualization is only supported in AArch32 mode. This will also be fixed
in a later patch.
Contributors:
Giacomo Gabrielli (TrustZone, LPAE, system-level AArch64, AArch64 NEON, validation)
Thomas Grocutt (AArch32 Virtualization, AArch64 FP, validation)
Mbou Eyole (AArch64 NEON, validation)
Ali Saidi (AArch64 Linux support, code integration, validation)
Edmund Grimley-Evans (AArch64 FP)
William Wang (AArch64 Linux support)
Rene De Jong (AArch64 Linux support, performance opt.)
Matt Horsnell (AArch64 MP, validation)
Matt Evans (device models, code integration, validation)
Chris Adeniyi-Jones (AArch64 syscall-emulation)
Prakash Ramrakhyani (validation)
Dam Sunwoo (validation)
Chander Sudanthi (validation)
Stephan Diestelhorst (validation)
Andreas Hansson (code integration, performance opt.)
Eric Van Hensbergen (performance opt.)
Gabe Black
Changes to make m5ops work under virtualization seemed to break them working
with non-virtualized systems and the recently added m5 fail command makes
the m5op binary not compile. For now remove the code for virtualization.
In order to support m5ops in virtualized environments, we need to use
a memory mapped interface. This changeset adds support for that by
reserving 0xFFFF0000-0xFFFFFFFF and mapping those to the generic IPR
interface for m5ops. The mapping is done in the
X86ISA::TLB::finalizePhysical() which means that it just works for all
of the CPU models, including virtualized ones.
Using arm-linux-gnueabi-gcc 4.7.3-1ubuntu1 on Ubuntu 13.04 to compiled
the m5 binary yields the error:
m5op_arm.S: Assembler messages:
m5op_arm.S:85: Error: selected processor does not support ARM mode `bxj lr'
For each of of the SIMPLE_OPs. Apparently, this compiler doesn't like the
interworking of these code types for the default arch. Adding -march=armv7-a
makes it compile. Another alternative that I found to work is replacing the
bxj lr instruction with mov pc, lr, but I don't know how that affects the
KVM stuff and if bxj is needed.
Changeset 5ca6098b9560 accidentally broke the m5 utility. This
changeset adds the missing co-processor call used to trigger the
pseudo-op in ARM mode and fixes an alignment issue that caused some
pseudo-ops to leave thumb mode.
This changeset adds support for m5 pseudo-ops when running in
kvm-mode. Unfortunately, we can't trap the normal gem5 co-processor
entry in KVM (it doesn't seem to be possible to trap accesses to
non-existing co-processors). We therefore use BZJ instructions to
cause a trap from virtualized mode into gem5. The BZJ instruction is
becomes a normal branch to the gem5 fallback code when running in
simulated mode, which means that this patch does not need to change
the ARM ISA-specific code.
Note: This requires a patched host kernel.
