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>
Instead of gating the behavior of DTRACE based on TRACING_ON in the
preprocessor, move it to C++. Beyond being a little simpler, this
ensures that the value of Debug::x is always valid (the proper header is
included, x is spelled correctly, etc) even if TRACING_ON is false.
Change-Id: Ie0085c0f8753ad5283ef1850d493706b977c21a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45006
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The code in the body of a DPRINTF will always be compiled, even if it's
disabled. If TRACING_ON is false, the if around it will short circuit to
false without actually running any code to check the specified
condition, and the body of the if will be elided by the compiler as
unreachable code.
This creates a more consistent environment whether TRACING_ON is on or
not, so that variables which are only used in DPRINTF don't have to be
guarded by their own TRACING_ON #ifs at the call site. It also ensures
that the code inside DPRINTF is always checked to be valid code, even if
the DPRINTF itself will never go off. This helps avoid syntax errors,
etc, which aren't found because of the configuration of the build being
tested with.
Change-Id: Ia95ae229ebcd2fc9828f62e87f037f76b9279819
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44988
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
GEM5_DEPRECATED(message) expands to the [[gnu::deprecated(message)]]
attribute on gnu compatible compilers and marks an entity (function,
variable, etc) as deprecated. The msg parameter should be used to tell
the user what they should do to move away from the deprecated entity.
GEM5_DEPRECATED_MACRO(name, definition, message) is used inside an
expression-like macro with definition "definition" to mark that macro as
deprecated with message "message". For instance, if there were macros
like this:
#define SUM(a, b) ((a) + (b))
#define ONE 1
We could mark that as deprecated like so:
#define SUM(a, b) GEM5_DEPRECATED_MACRO(SUM, (a) + (b), \
"The SUM macro is deprecated, use the + operator instead.")
#define ONE GEM5_DEPRECATED_MACRO(ONE, 1, "Use the literal 1.")
Note that this macro should not be used for macros which, for instance,
declare variables, since it assumes the body of the macro expands into
an expression and not a statement or statements.
Change-Id: I58f5e834cfeeb23e37a6548433dfe7e4f695a5ec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45086
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This macro is directly expecting a Debug::Flag instance as a first
argument instead of simply the name of the debug flag, and it is
forwarding it with no preprocessing to the underlying logic
(dprintf_flag).
This is different from the common DPRINTF, which is converting the
first argument into a flag and into a string literal.
This is useful if we want to pass the DebugFlag from the subclass to
the superclass. This makes it possible to set tracepoints in the
Base class logic, and let the Derived classes define the flag which
will enable the tracepoint
class Base
{
Base(const Debug::SimpleFlag &_flag)
: flag(_flag) {}
void baseLogic()
{
DPRINTFV(flag, "...");
}
const Debug::SimpleFlag flag;
}
class Derived1 : public Base
{
Derived1() : Base(Debug::Derived1) {}
}
class Derived2 : public Base
{
Derived2() : Base(Debug::Derived2) {}
}
A more concrete example is Arm Table Walker, which is using a DmaPort.
If we want to log the table walker port activity, we are using the
--debug-flags=DMA, which is unconvenient as it will contain the
logs from every DMA device in the simulation
Change-Id: I793cf1521303fd0a3bbea2059a9447386f83661e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44967
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>
Only one is set up corrent, the one passed in from the constructor.
Others can be added with addThreadContext.
The inconsistency of adding one ThreadContext through the constructor
and others through addThreadContext isn't great, but this way we can
ensure that there is always at least one ThreadContext. I'm not sure
what the GDB stub should do if there aren't any threads. I don't think
that the protocol can actually handle that, judging from the
documentation I can find.
Change-Id: I9160c3701ce78dcbbe99de1a6fe2a13e7e69404e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44611
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>
