Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.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>
Since gtest's SUCCEED() just throws away output sent to it, there needs
to be an alternative way to capture non-fatal warn, hack, or inform
messages. This change adds a stringstream called gtestLogOutput which
will accumulate all log messages so they can be inspected later. If you
want to see what output occurs as a result of a specific action, you can
flush out the stringstream with .str(""), perform that action, and then
check the stream's contents.
The stream also records the output of exiting logs like fatal and panic.
It's not 100% clear that these messages would be retrievable or useful,
but this at least maintains consistency between the two classes of
messages.
To avoid threading/locking issues, the stream is thread local. To
prevent tests from affecting each other and to make the output more
predictable for test assertions, it also automatically installs an event
hook which will be called each time a test starts which will clear out
the contents of the stream.
Change-Id: I9d6650feb77b676a5b2b1fc2542cdebf3c60ed34
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42181
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously the `GTestExitLogger.log` function utilized GTest's
`ADD_FAILURE_AT` macro. This meant, whenever `GTestExitLogger.log` were
called, the calling test would be fail. This is problematic when
trying to test code we expect to fail (i.e., when testing the error
handling code is working correctly). Therefore, the `log` function now
writes to stderr.
The `GTestExitLogger` class is used by the `panic` and `fatal` loggers
when running GTests. Instead of callnig `exit(1)` they throw a GTest
exception, which can be captured in a test using
`EXPECT_ANY_THROW(expection_thrower())`. Catching and verifying error
logs can be done via:
```
testing::internal::CaptureStderr();
/*
* "exception_thrower()" is a method we'd expect to call `fatal` or
* `panic`, and therefore exit the simulation with a non-zero exit
* code. When running via GTest, an exception is thrown instead.
*/
EXPECT_ANY_THROW(exception_thrower());
EXPECT_EQ("<error message>", testing::internal::GetCapturedStderr()));
```
Change-Id: I84a5f86bc573668d3dd5b40f626b43108dddb8e9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23983
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
On exiting log types (panic and fatal), the message is set to an
ADD_FAILURE_AT macro, and the test is exited by throwing an otherwise
unexpected exception. On non-exiting log types, the message is sent to
the SUCCEEDED macro which currently doesn't output anything.
Change-Id: I1bb569e6cb8308dbc4c3e04eea7a962bd2b1ddd8
Reviewed-on: https://gem5-review.googlesource.com/6264
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
