These functions where correctly returning whether a flag had existed,
and also correctly not installing it if asked not to. Unfortunately if
they *were* asked to install the flag, they ignored whether or not it
had actually existed to begin with.
Change-Id: I2dca0e1a0ddbc182576d48237aeea5452a02c51b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41159
Maintainer: Gabe Black <gabe.black@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This check used uname to determine if scons was running on macos, and
then a fairly elaborate check to see if the version was above 9, and if
the hardware supported 64 bit. I think at this point it's safe to assume
both that we're at least at macos 10 which is 19 years old, and that Mac
hardware supports 64 bit.
Change-Id: Ice66df2530bbcc929d3a37e7679634b75ba7b860
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40857
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
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>
