When an object is a field in a union, it's the programmer's
resposibility to destroy it from the union's destructor. We can simply
neglect to do that and avoid having to use new to create the flags.
Also, we can define the flags as inline variables (a c++17 feature), and
then create a constexpr references to them. This lets us refer to debug
flags in constexpr objects, although we can't interact with them at, for
instance, construciton time or we'd lose our own constexpr-ness since
the actual object is not constexpr.
In c++20 we would hypothetically be able to use constexpr with new and
delete, but there may be additional restrictions that would make this
particular use impossible. Also this avoids leaking memory, which, even
though it's intentional, may confuse tools like valgrind.
Also, we need to ensure that all headers are included in some source
file so that they exist in the final executable, so that they show up in
the help, can be enabled/disabled, etc.
Change-Id: Ia43111d938e7af7140b1c17dd68135f426d0a1e9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49783
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jui-min Lee <fcrh@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It's really a part of the build system and not part of gem5, and so it
should probably live outside of the main tree. It would be confusing to
have a bunch of python scripts which don't end up inside gem5 alongside
a bunch of ones that do in src/python.
The directory is called build_tools instead of build so it doesn't get
confused with an actual build output directory.
Change-Id: Ie12475a15517508dc2044f0ca4db71a601b7ab6d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49393
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
