This avoids boilerplate where we check to see if flag X is supported,
and if so then set flag X. Since there are shared and static versions of
the linker flags but we only explicitly check the static ones, this
change also adds a parameter to CheckLinkFlag to set both flavors. This
defaults to true since I assume most of the time linking flags will
apply to both.
Change-Id: I983222169e9835aeb98570362f7004e2ef0240d0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40855
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If supported this will compress the debug information in object files,
libraries, and binaries. This decreases the size of the build/ARM
directory from 11GB to 7.2GB.
Because the benefit of this mechanism depends on the performance and
capacity of the build machine's storage, it can be disabled with the
--no-compress-debug scons flag. For instance if your storage is very
fast, writing out a larger binary may take less time than compressing
that same number of bytes, plus the time to write out the smaller
file.
This feature seems to make our presubmit test machine run out of memory
when trying to build gem5, and so is disabled in the testing scripts.
Change-Id: I71919062d23742b7658918b0fa9c4d91d0521fbf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40715
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit adds an option to add SI and its derived units to stats.
Units are now the third parameter of every Stat class constructor.
The following are convenient macros that could be used to add units
to stats,
* UNIT_CYCLE: represents clock cycles.
* UNIT_TICK: represents the count of gem5's Tick.
* UNIT_SECOND: represents the base unit of time defined by SI.
* UNIT_BIT: represents the number of computer bits.
* UNIT_BYTE: represents 8 bits.
* UNIT_VOLT: a SI derived unit measuring potential difference.
* UNIT_JOULE: represents joule, a unit of energy, as defined by SI.
* UNIT_WATT: represents 1 watt, where 1 watt = 1 joule / second.
* UNIT_CELSIUS: represents 1 Celsius degree as defined by SI.
* UNIT_RATE(T1, T2): represents the unit of a quantity of T1 divided
by a quantity of T2.
* UNIT_RATIO: represents the unit of a quantity of unit T divided by
a quantity of unit T.
* UNIT_UNSPECIFIED: the unit of the stat is unspecified. This type of
unit is mainly for backward compatibility. Newly
introduced stats should have the units specified.
This commit also alters the behavior of the ADD_STAT macro.
Specifically, ADD_STAT syntax is unchanged, but the unit of the stat
is hardcoded to be UNIT_UNSPECIFIED.
JIRA link: https://gem5.atlassian.net/browse/GEM5-849
This change is an effort towards supporting new stats schema:
https://github.com/gem5/stats-schema
Change-Id: I791704a6c4d9e06332797dbfc5eb611cb43f4710
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38855
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
The idea of this template was to distinguish types which should
grow/shrink based on the native size of the ABI in question. Or in other
words, if the ABI was 32 bit, the type should also be 32 bit, or 64 bit
and 64 bit.
Unfortunately, I had intended for Addr to be a conforming type (since
local pointers would be conforming), but uint64_t not to be. Since Addr
is defined as a typedef of uint64_t, the compiler would make *both*
types conforming, giving incorrect behavior on 32 bit systems.
Local pointers will need to be handled in a different way, likely with
the VPtr template, so that they will be treated correctly and not like
an explicitly 64 bit data type.
Change-Id: Idfdd5351260b48bb531a1926b93e0478a297826d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40495
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This test expects to load a symbol file using the load method of gem5's
SymbolTable class, and then to search through it for a given symbol or
address.
Unfortunately, the type of file it expects to load has a format where
each line is of the form:
0x00000000, symbol_name
where the numerical part is the address of the symbol, and the part
after the comma is the symbol name. I have not been able to find any
tool which outputs a symbol file in this format, or any tool for
inspecting an existing object file which will output symbols in this
format. I looked at objdump, objcopy, nm, and the map file format output
by gnu's linker. nm has 3 different output formats, none of which match.
Usually when working with ELF files, one would just generate a new ELF
file which only had debugging information like the symbol table, and
then strip the symbols out of the original.
Since this file format seems to have been invented from thin air, there
isn't really a good way to generate a canonical file to test the loading
code against, nor is being able to load this obscure format likely to be
useful to anybody. If someone *did* want to load an external symbol
table, they would use the ELF loader and not this.
This CL deletes both this test, and the loading code in SymbolTable.
Change-Id: I20402e3f35e54d1e186a92d9c83d1c06ec86bf7d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40620
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The 32-bit POWER reference test binary was removed in c1ebdf66f
(as a nasty surprise for POWER users).
The remaining platforms split between two approaches:
MIPS rebuilds "hello" from source.
This fails for two reasons:
1) The trivial reason is that on POWER make abends due to no makefile.
2) The more fundamental reason is that gem5 is not completely bug-free
(especially the Decoder on POWER in this case), therefore regression
testing is only possible if we have not just some hello program, but
a very particular bit sequence to serve as an immutable reference.
ARM and X86 follow the reference-bit-sequence approach. POWER will
be consistent with same. Including the sha1 for hello32,
77b27b67393311546e768b5ff35202490bad71aa, as a simple immutability
assurance. I have also renamed hello to hello32 in anticipation to
merge Sandipan's e52dbcb.
Change-Id: I77ef31349c9e50b987c6f58bb23324844527366d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40635
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-by: Pratik Sampat <pratik.r.sampat@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The default type for VPtr is now void, and the void partial
specialization of VPtr is basically just a fancy container for Addr. Its
purpose is to distinguish guest addresses from actual uint64_t-s in the
signature of simcalls so that types which are purposefully 64 bits will
stay that way, and addresses will scale to the size of pointers in the
target ABI.
Change-Id: I71e2201f5917005861ba678c6675dbcbaa0965b3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40497
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This type is primarily used to determine the size of a pointer when
using that ABI, similar to the uintptr_t type, but also less directly
to determine the "native" size of the ABI. For instance, for 32 bit ARM
ABIs, it should be defined as uint32_t since that's both the size of a
uintptr_t, and, less directly, the size of a 32 bit ARM register and
"naturally" sized types in that ABI.
This type can be used by the VPtr template to retrieve its actual value
from a simcall's parameters. In general, when accepting or returning a
pointer or address in a simcall, the VPtr template should be used so
that it's managed correctly by GuestABI. Addr will be treated as a
uint64_t allways which will be incorrect for 32 bit ABIs.
Change-Id: I3af046917387541d6faff96a21a1f1dbf7317e06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40496
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Although they provide the exact same behavior, the params
created in the tests did not have the type expected by the
internal safe cast.
The following error was triggered:
storage.test.debug: build/NULL/base/cast.hh:47: T safe_cast(U)
[with T = const Stats::SampleStor::Params*;
U = const Stats::StorageParams*]:
Assertion `ret' failed.
Change-Id: I4f2ba51f3ccdb44589e61f235997245e7d9bf3c9
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40555
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
These files were originally used to provide a more gtest like mechanism
for the UnitTest executables, many of which didn't actually test
anything. With the definitions in those files, the tests could check
whether their expectations were met, and either pass or fail without a
human having to inspect the output and knowing what output to expect.
Change-Id: Ie0601391b994859eb544b37201333838fa3ba02a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40618
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This "UnitTest" was really not a unit test, it was a timing utility for
measuring the performance of gem5's cprintf implementation. The name was
misleading, but more than that, it was linked against all of gem5 which
created a approximately 1.5 gigabyte binary for what is a very small
program.
Instead, the new version of cprintftime, which has the same
functionality as the old version, weighs in at a svelte 500k with debug
information.
This also trims down the number of misleading "UnitTest" entries to 3,
getting us closer to the point where we can eliminate that type of
entity entirely.
Change-Id: Id30d094f2844e948fe67e820c89412f8667aaa52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40617
Maintainer: Gabe Black <gabe.black@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
That tag was intended to mark an Executable subclass as abstract, aka
only suitable for using as bases for other Executable subclasses and not
for direct instantiation. The only place it was used was the base
Executable class however, and that class is actually directly useful
when setting up a generic executable from other gem5 sources.
Change-Id: I70204b63c03bb45bf21b8c312a7b8581be5e0cab
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40616
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This DPRINTF accesses the ExtMachInst typed machInst member of the
StaticInst class, and so is ISA dependent. Move the DPRINTF to where the
instructions are actually decoded where that type doesn't have to be
disambiguated.
Also, this change makes this DPRINTF more accurate, since microops are
not really "decoded" when they are extracted from a macroop. The process
of unpacking them to feed into the rest of the CPU should be fairly
trivial, so really they're just being retrieved. With the DPRINTF in
this new position, it will only trigger when an instruction is actually
decoded from memory.
Change-Id: I14145165b93bb004057a729fa7909cd2d3d34d29
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40099
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 only way to allocate fixed sized arrays which will definitely be big
enough for all source/destination registers for a given instruction is
to track the maximum number of each at compile time, and then size the
arrays appropriately. That creates a point of centralization which
prevents breaking up decoder and instruction definitions into more
modular pieces, and if multiple ISAs are ever built at once, would
require coordination between all ISAs, and wasting memory for most of
them.
The dynamic allocation overhead is minimized by allocating the storage
for all variable arrays in one chunk, and then placing the arrays there
using placement new. There is still some overhead, although less than it
might be otherwise.
Change-Id: Id2c42869cba944deb97da01ca9e0e70186e22532
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38384
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Per the AMD64 Architecture Programming Manual:
The size of the count register (CX, ECX, or RCX) depends on the
address-size attribute of the JrCXZ instruction. Therefore, JRCXZ can
only be executed in 64-bit mode
and
In 64-bit mode, the operand size defaults to 64 bits. The processor
sign-extends the 8-bit displacement value to 64 bits before adding it
to the RIP.
This patch also renames the instruction from JRCX to JRCXZ to match the
language in the programming manual.
Change-Id: Id55147d0602ff41ad6aaef483bef722ff56cae62
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40195
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
