Debug flags were directly declared as global objects; however, the
destruction order of global objects in different translation units are
not defined in c++, so the destructor of other objects cannot safely
utilize debug flags to output extra information.
We now define those flags as references to objects allocated on the heap
so our flags will never get destructed. Note that this won't really
introduce any memory leak, as the program is getting terminated anyway.
Change-Id: I21f84ae17ac20653636ca67d1111c0c7855c0149
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45582
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
This can be used to send a functional packet from the perspective of a
thread context. Currently this will not consider targets within the CPU
like the local APIC on x86. The default implementation sends a packet
using the port on the way out of the CPU.
Change-Id: Idb311e156a416ad51b585794c1e9fa75711d61f1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45861
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
These versions of g++ don't handle parameter pack expansion correctly
when there is a parameter pack defined at the class level and then one
which is defined by the constructor itself. Even though it knows what
the outter parameter pack contains, it still re-assigns it to be empty
and puts all arguments into the later parameter pack.
To work around this problem, we will explicitly put the class level
parameters into a tuple, which we then have to go through extra
acrobatics to explode and pass into base class constructors.
That also means that in all subclasses, the arguments which go into the
tuple need to be wrapped in {}s to group them into constructor arguments
for the tuple.
Change-Id: I3139eebd7042b02f50862d88be5c940583a2a809
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45820
Maintainer: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
sinic::Regs became sinic::registers.
"registers" was chosen over "regs" to reduce conflict
resolution (there is already a variable called regs).
Change-Id: I329d40884906bb55d1b1d749610b9f0dee243418
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45388
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
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>
When a fault is generated, it needs to be returned, and nothing else
should be done. There's no point in keeping it around and having to
check over and over if there was a fault and if other parts of the
execute functions should be skipped.
This simplifies the logic a bit which should speed up execution, and
also makes life easier for the compiler since behavior is obvious and
doesn't have to be deduced from possible data values and ifs.
Change-Id: I2004c7d22ac6222e1ef2acb51d49b4eb2e60b144
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45520
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Aside from basic code editting, this also moves some methods from the
.hh files to the _impl.hh files. It also changes the Checker CPU
template to take the DynInstPtr type directly instead of through Impl
since that was the only type it used anyway. Finally it sets up a header
file which predeclares the O3DynInstPtr and O3DynInstConstPtr types so
they can be used without having to also include the BaseO3DynInst class
definition to break circular dependencies.
Change-Id: I5ca6af38ec13e6e820abcdb3748412e4f7fc1c78
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42101
Reviewed-by: Nathanael Premillieu <nathanael.premillieu@huawei.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
