As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::Stats became ::statistics.
"statistics" was chosen over "stats" to avoid generating
conflicts with the already existing variables (there are
way too many "stats" in the codebase), which would make
this patch even more disturbing for the users.
Change-Id: If877b12d7dac356f86e3b3d941bf7558a4fd8719
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45421
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 thing brought in by arch/types.hh is TheISA::PCState. Instead
of having the other types around where they could be used accidentally,
and to make it more obvious what's being exported, this change splits
PCState out into a new switching header called arch/pcstate.hh. The
original arch/types.hh is no longer a switching header, and includes
pcstate.hh.
Change-Id: I8dfd298349e4565f316f7b9a028703289ada6010
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40177
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
By moving the installation of even the first ThreadContext out of the
constructor, it's possible to construct the stub separately. We can then
move the code that creates the stub out of the base class and into
architecture specific sub-classes.
Change-Id: I0dfd53a3135ebc98ec49acf81d83e58830bc365c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44618
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
When connecting to a thread, the remote GDB stub will try to wait for an
instruction boundary before proceeding. Since the CPU the thread context
is attached to may be inactive, it may not get around to reaching an
instruction boundary, and the event may not happen for an indefinite
period of time.
Instead, assume that inactive CPUs are already at instruction
boundaries, and trigger the event manually.
Change-Id: I9a67a49f9a52bdf9b1f0b88a1d173aa2bdfb5a16
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44612
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Loggers was previously declared as global variables, hence are unsafe to
be used inside other global objects' destructor (e.g. scMainFiber). This
CL makes them heap allocated objects hold by function static variables.
As a result:
1. The loggers never get destructed at the end of program, which makes
them safe to be used in global objects' destructor.
2. The loggers are constructed ondemand instead of relying on linker's
unknown way of ordering, which makes them safe to be used in global
objects' constructor.
Change-Id: Ieb499d2fa4c5c1c015324cb72b055115b0933ab8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46079
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>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
sim_clock::Float became sim_clock::as_float.
"as_float" was chosen because "float" is a reserved
keywords, and this namespace acts as a selector of
how to read the internal variables. Another
possibility to resolve this would be to remove the
namespaces "Float" and "Int" and use unions instead.
Change-Id: I7b3d9c6e9ab547493d5596c7eda080a25509a730
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45435
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
The existing template would apply the helper operator to *any* template
which took two types, regardless of what that template was. The
assumption was that those types *must* be STL containers, because no
other template takes two types, right?
Instead, this new version uses type traits to explicitly whitelist types
which the helper applies to. Currently the only type it seems to be used
with is std::vector, but by defining more specializations of
IsHelpedContainer, other types/templates can be enabled as well.
This is particularly important when moving to c++17, since the
std::string class would then apparently match the old overload. That
makes the << operator ambiguous and breaks the build.
Change-Id: Id283746a2ccced8882fa23e6f9e69fe22e206b70
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45901
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The GEM5_DEPRECATED_NAMESPACE macro temporarily declares
a namespace with the deprecated name that prints a
warning message when used. It also make sure that when
the old namespace name is used the new name is referenced.
The GEM5_DEPRECATED_CLASS macro deprecates classes that
were renamed, or moved to different namespaces.
Attributes in namespaces are an issue, though.
- Clang only allows from version 6 on, and only when
using C++17.
- GCC has a bug before version 10 where the deprecated
attribute was not properly recognized in namespaces:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79817
Possible solutions for GCC < 10:
1)
\#define GEM5_DEPRECATED_NAMESPACE() \
namespace gem5 { namespace deprecated { \
auto namespace_##old_namespace = [](){ \
GEM5_DEPRECATED("Please use the new namespace: '" \
\#new_namespace "'") \
int old_namespace; \
return old_namespace; \
}; \
}} \
namespace new_namespace {} \
namespace old_namespace { \
using namespace new_namespace; \
}
Add the above macro to all headers that previously
declared the deprecated namespace to trigger a
warning. This is extremely inconvenient because
every file that includes that header will trigger
the deprecation warning, so the compilation output
gets VERY clogged.
2) Similar to 1), but do not use the temporary variable
on declaration. This would require using the variable
somewhere else, like a respective .c file. This is
not always possible, so we could resort to adding a
special file (e.g., base/deprecated_elements.cc)
containing all uses of the deprecated temporary
variables.
3)
\#define GEM5_DEPRECATED_NAMESPACE(old_ns, new_ns) \
namespace old_ns = new_ns;
Similar to 3), but simply declare an alias in the
header files (see above macro) to maintain backwards
compatibility. Then use the special file to declare
all deprecation messages.
4)
Rely on release notes / e-mail to the mailing list
to inform that those are deprecated.
We have selected option 4 for these problematic instances.
Checking if namespace deprecation is possible is done
through scons.
Jira issues:
https://gem5.atlassian.net/browse/GEM5-975https://gem5.atlassian.net/browse/GEM5-991
Change-Id: Ide234f6a8707d88a869fa843bf8c61ca7714e4f3
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45246
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 macro in base/inet.hh, HOME_ADDRESS_OPTION, was not used by
anything. The IP6_EXTENSION macro was replaced with a static inline
function called ip6Extension. The awkward nested ternary operator was
replaced with an equivalent ||.
Change-Id: I100894811159b39b964a49c43a09d493d1268739
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45739
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Since DPRINTFS is a macro, its arguments need to be properly wrapped so
they expand as expected when used in expressions. This wasn't being done
for the s argument which was used as s->name(). If s contained some
other operator which had lower precedence than ->, the -> would happen
first to whatever was on the right hand side.
Change-Id: Id3250abb9ba51c4b0740f8de0d80ed730ba96944
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45619
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Also add macros which define the old names to the new names for
backwards compatibility.
This change also takes the opportunity to rename the M5_ATTR_PACKED
macro to GEM5_PACKED, dropping the ATTR. None of the other attribute
based macros bother to specify that they stand for an attribute, making
this one inconsistent and overly verbose.
Similarly, it renames M5_NODISCARD to GEM5_NO_DISCARD to be consistent
with other macros which separate out individual words like GEM5_VAR_USED
and GEM5_NO_INLINE
Change-Id: I22d404492faf28b79a8247f869f14af21c9cf967
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45230
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are HDF5, PNG, FENV, and TUNTAP support, all of which add
capabilities to gem5 which can be ignored if not wanted. It could be
argued that FENV changes behavior because it makes setting the FP
rounding mode work or not as used by SPARC, but since the difference is
trivial and in a niche area, that (along with the other options) doesn't
seem to justify having a top level control in the build system.
Since these are no longer options which say whether to *use* a
particular feature, and are instead flags which say whether we *have* a
particular feature, change their names from USE_* to HAVE_*, to stay
consistent with other variables.
Most of the remaining USE_* flags, KVM, FASTMODEL, SYSTEMC, and
(indirectly) USE_PYTHON, toggle on and off major systems which can have
a significant effect on boot time, or, in the case of FASTMODEL, even
consume external resources which may not be available and which may
break the build.
USE_POSIX_TIMER was also left alone since it selects between two
implementations of some functions. By forcing it to be on or off
depending on the host, we would be forcing some code to be excluded in
either case. That would make that other code impossible to test without
hacking up scons or modifying the host machine.
Change-Id: I0b03f23e65478caefd50cd3516974386e3dbf0db
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40964
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Compound debug flags are intended to be a way to enable or disable a
group of simple debug flags at once, so that you don't need to enumerate
every more specialized flag in an area to get a broad amount of
debugging, nor do you give up the ability to select a general area
easily by making more specific flags.
It doesn't, however, make a lot of sense to check the value of a
compound debug flag, since it could be enabled but then have individual
subflags disabled. Exactly whether that means the compound flag should
be enabled or not is not clear, and figuring it out takes a fair amount
of work since each member simple flag needs to be visited.
Also, by having different behavior depending on the flag type, the
"enabled" method needed to be virtual.
This change eliminates the virtual method and moves the _tracing bool
member into the base class. If a subclass (only SimpleFlag currently)
wants to start or stop tracing based on itself, it should set or clear
this flag. Also, the "enabled" method has been renamed to "tracing",
since that's actually what it tracked. Being enabled by itself is not
sufficient to be tracing since there is also a global enable.
Finally, rather than duplicate the logic to convert a flag to bool in
the python wrapper, we can just use a cast to bool and take advantage of
the version in C++.
Change-Id: I3dc64c2364f0239294093686ddac6fcc8441f306
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45007
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
