Because the python environment may already be up and running by the time
static initializers are run, specifically when gem5 is built as a
library and loaded with dlopen, we can't rely on all of the objects
declaring python initialization callbacks having been constructed by the
time the code which would execute them runs.
To address that problem, this change keeps track of whether the
initialization has already happened when a callback is installed, and if
so, runs the callback immediately.
The original implementation also had users install callbacks by
overriding a virtual function in the PythonInitFunc class, and then
statically allocating an instance of that subclass so its constructor
would be called at initialization time. Calling the function manually if
initialization has already happened won't work in that case, because you
can't call a virtual function from a constructor and get the behavior
you'd want.
Instead, this change makes the PythonInitFunc wrap the actual callback
which is outside of the structure itself. Because the callback is not a
virtual function of PythonInitFunc, we can call it in the constructor
without issue.
Also, the Callback type has to be a bare function pointer and not a
std::function<...> because the argument it takes is a pybind11::module_
reference. Pybind11 sets the visibility of all of its code to hidden to
improve binary size, but unfortunately that causes problems when
accepting one as an argument in a publically accessible lambda in g++.
clang doesn't raise a warning, but g++ does which breaks the build. We
could potentially disable this warning, but accepting a function pointer
instead works just as well, since captureless lambdas can be trivially
converted into function pointers, and they don't seem to upset g++.
Change-Id: I3fb321b577090df67c7be3be0e677c2c2055d446
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54325
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This should help reduce warning spew when building with newer compilers.
The pybind11::module type has been renamed pybind11::module_ to avoid
conflicts with c++20 modules, according to the pybind11 changelog, so
this CL also updates gem5 source to use the new type. There is
supposedly an alias pybind11::module which is for compatibility, but we
still get linker errors without changing to pybind11::module_.
Change-Id: I0acb36215b33e3a713866baec43f5af630c356ee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40255
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
