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>
I switch between waiting and non-waiting scenario many times per day.
The BaseCPU.wait_for_remote_gdb attribute, introduced in c2baaab0ed,
makes it much less painful by saving many recompiles.
The present commit tries to go a bit further: the se.py script is
under version control, and changing it interferes with smooth git
workflow.
Change-Id: Ie65ffc44b11d78d5e7878f81f2fcdafa143c20a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27287
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This proxy was only used by the ARM semihosting interface which can now
use a tweaked regular TranslatingPortProxy or SETranslatingPortProxy
instead of this special purpose class.
This sort of class would still be necessary if you wanted to use
physical addresses and not virtual addresses, but presently there is no
such use. This code can be retrieved from history if it's needed in the
future.
Change-Id: Ie47a8b4bb173cba1a06bd3ca60391081987936b8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26625
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
This is to match the FVP Foundation platform.
Priviledged software could query the SYS_ID register in the V2m
Motherboard controller to extract platform information:
https://
static.docs.arm.com/100961/1110/armv8_a_fp_ug_100961_1110_00_en.pdf
In particular:
* SYS_ID[31:28] (REV) = Revision Number
** Value = 0x3 -> FVP Foundation v9.6
* SYS_ID[27:16] (HBI) = Board Number
** Value = 0x010 -> FVP Foundation platform
* SYS_ID[15:12] (BLD) = Which variant of the GIC memory is implemented
in the model
** Value = 0x1 -> (!= legacy VE memory map)
* SYS_ID[11:8] (Arch) = Architecture
** Value = 0x1 -> Architectural model (FVP)
Change-Id: Ib9395eb872cb925c029077acfdd18e48478f779b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27184
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The bug(s) which prevented LTO and partial linking from working with gcc
have been fixed in my local version (9.3), and according to one of the
original bug reports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
A fix was committed in gcc version 8.1.
The original code left in the SConstruct describing the problem with
versions greated than 6.0 also enabled an -flinker-output option and set
it to "rel". That option doesn't show up in the gcc 8.4 documentation
even though it was added in 6.0, but in the 9.3 documentation it
describes it and says that it defaults to "rel" when the -r (partial
linking) option is used.
This *should* mean that LTO and partial linking can be used together
with no issues after version 8.1, and at most by version 9.3. If someone
finds that that isn't true, then the range of bad versions can be
expanded.
Change-Id: Ie0529d077a0042ef55e2af995d01430d1695c031
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27131
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This is in the range of call numbers set aside for extensions. When
called, it will extract the function to use from the first argument
slot. Then it calls the pseudoInst dispatching function using an ABI
which drops the return value (which is handled by semihosting itself)
and which extracts arguments from the remaining slots in the param
structure.
This makes gem5 pseudo ops available on CPU models which support
semihosting but not instruction based or address based "magic"
operations, aka hypercalls. This includes the fast model CPUs.
Change-Id: Ic4817f2b1e6aad7784af77a1a494cf614d4d4c6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25950
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When building gem5, it's possible for warnings printed early in the
build to be quickly wisked away in a see of compile lines, never to be
seen again (or driven off the end of the scrollback buffer).
To avoid those messages getting lost or ignored, this change adds a
mechanism to aggregate them into a list so that they can be summarized
at the end of the build, successful or not.
Change-Id: Ie13320717698fcbcd3a8f8d1c062467e8d6d2914
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27129
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Otherwise the error and warning messages get chopped off and wrapped by
the terminal wherever they happened to end. That's ugly and hard to
read.
This mechanism attempts to wrap the text using the console width which
it attempts to determine in two ways, first with shutil which should
work in python 3.3 and above, and then with the curses python module. If
neither of those works, it just falls back to 80 columns which is not
ideal but is reasonable.
Change-Id: I961936295505f93f5f36eb6d9cebc5073b5f793b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27128
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is another fix for the AArch32-AArch64 interprocessing issue
introduced in
3d15150d cpu, arch, arch-arm: Wire unused VecElem code in the O3 model.
Register mapping between AArch32 and AArch64 is explicitly defined in
ARMv8 manual. This allows software to read registers right after a state
switch without writing them first, and it is indeed common for software
to save registers to memory first before using them.
In gem5's implementation of vector mode switching, however, vectors may
not be marked as ready right after a state switch. Software reads toward
vectors at this time will stall O3CPU forever. This patch fixes this by
marking all mapped vectors (or vector elements, depending on AArch32 or
AArch64) as ready right after switching vector mode.
Change-Id: I609552c543dad8da66939c0a3079d73d48e92163
Signed-off-by: Hsuan Hsu <hsuan.hsu@mediatek.com>
Signed-off-by: Howard Wang <Howard.Wang@mediatek.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26203
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Fix MOESI_hammer checkpoint hanging.
The function markRemoved() should be called before hitCallback(),
not after it. The reason is that hitCallback() checks if draining is
complete based on the value of "m_outstanding_count". And since
markRemoved() is responsible for decrementing "m_outstanding_count",
hitCallback() does not see that there are no outstanding requests.
Reported by: Timothy Hayes
Jira: https://gem5.atlassian.net/browse/GEM5-331
Change-Id: I14c34be79843b172ae994ab1792fe4ce6cf5cf6e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25683
Reviewed-by: Timothy Hayes <timothy.hayes@arm.com>
Reviewed-by: John Alsop <johnathan.alsop@amd.com>
Maintainer: Bradford Beckmann <brad.beckmann@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
scons maintains an environment (in the shell sense) in the ENV
construction variable for use when running external programs. When we
run the "marshal" program which gathers up python objects to embed in
the gem5 binary, it's run by subprocess instead of through scons, and it
uses its own environment inherited from the host system.
Instead, this change makes the subprocess function use the scons
environment when calling "marshal". This ensures the environment is
consistent between this command and other commands scons runs.
This is usually not very important, but some tools like asan take
options set through the environment, and they may need to be adjusted
sometimes.
Change-Id: I671b447657ed8fad45fac7393cc1c09073bf3d3a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27123
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
ARM's semihosting interface defines call numbers up to 0xff to be
for standardized use, and says that custom calls should go above this
number.
This new mechanism will let the caller decide whether it wants to
enable these extended calls, or if they should be ignored and only
standard calls should be recognized.
Change-Id: I34b01a4439c8a88242971ac486e34d810b054baf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25947
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This updates the syscalls for mmap, munmap, and mremap. The mmap
changes now create a virtual memory area through the MemState class
to allow for lazy allocation of mmapped regions. This provides
substantial performance boost for sparse usage of mmaps. The munmap
syscall is added to reclaim the virtual memory area reserved for the
mmapped region. The mremap syscall moves or resizes an mmapped region
and updates the corresponding virtual memory area region to keep the
page tables in sync.
Change-Id: Ide158e69cdff19bc81157e3e9826bcabc2a51140
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26863
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Switch over to the new MemState API by specifying memory regions for
stack in each ISA, changing brkFunc to use MemState for heap memory,
and calling the MemState fixup in fixupStackFault (renamed to just
fixupFault).
Change-Id: Ie3559a68ce476daedf1a3f28b168a8fbc7face5e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25366
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Extend the MemState API to handle tracking dynamically sized memory
regions of a Process class which may be added, moved, removed, or
change in size during the course of simulation. This utilizes the
virtual memory areas (VMA) class to track individual regions and
provides a fixup method to handle physical page allocation in case of
a page fault. This allows for lazy allocation of the stack, heap, and
mmap regions of memory.
Change-Id: I3ef10657e5f8e8f0e328bdf0aa15a27b1dde39bf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25483
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This patch extends the IntrControl to provided additional member
functions for (1) clearing all pending interrupts in a PE and (2)
checking for any pending interrupt in a PE. These are intended to
be used from interrupt management related peripherals.
Change-Id: I06b553872ed469e7449b872a0716865773ace154
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26809
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Remove the ability to not have an implementation for a semihosting call
in 32 or 64 bit mode since that was not actually being used. It can be
reintroduced if needed in the future.
Turn the physProxy helper function into a static function which
maintains a single secure port proxy. That makes the proxy available
outside of the ArmSemihosting class itself.
Change-Id: Ie99e7d79c08c039384250fab0c98117554c93128
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25946
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Some compilers won't build ARM due to how guest ABI
has been implemented.
The error is: "left shift count >= width of type"
[-Werror=shift-count-overflow]
The error is triggered when there is a left shift > the variable size
(in bits); this leads to undefined behaviour.
This is a compile time vs run time problem; the code is technically
fine, but the compiler is not able to understand this.
For example in aapcs64:
struct Argument<Aapcs64, Integer, typename std::enable_if<
std::is_integral<Integer>::value>::type> : public Aapcs64ArgumentBase
{
[...]
if (sizeof(Integer) == 16 && state.ngrn + 1 <= state.MAX_GRN) {
Integer low = tc->readIntReg(state.ngrn++);
Integer high = tc->readIntReg(state.ngrn++);
high = high << 64;
return high | low;
}
}
Even if the sizeof operator will be evaluated at compile time,
the block will be executed at runtime: the block will still be part of
the code if Integer = uint32_t.
The compiler will then throw an error because we are left shifting an
uint32_t by 64 bits.
Error arising on:
Compiler: gcc/5.4.0
Distro: Ubuntu 16.04 LTS
Change-Id: Iaafe030b7262c5fb162afe7118ae592a1a759a58
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26990
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are a few problems with this check.
1. Many ISAs support multiple page sizes.
2. Memories (particularly small ROMs) may not actually be in multiples
of the page size.
3. In a heterogenous environment, there won't be a single page size even
if each ISA picks a canonical page size.
4. Other than catching some egregious configuration mistakes, there's
nothing functionally wrong/different about a memory that isn't evenly
coverable in pages, especially in systems or configurations that
don't even use paging.
Change-Id: I3cd241657318d2e3fd5a1226cb54fdebbf172788
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26423
Maintainer: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
