summaryrefslogtreecommitdiff
path: root/src/python/pybind11
AgeCommit message (Collapse)Author
2017-08-30python: Make GlobalExitEvent.getCode() return an intAndreas Sandberg
PyBind normally casts integers returned from the C to long in Python. This is normally fine since long in most cases behaves just like an int. However, when passing the return value from getcode() to sys.exit, unexpected behavior ensues. Due to the way the function is defined, any type other than int (with the exception of None) will be treated as an error and be equivalent to sys.exit(1). Since we frequently use the sys.exit(event.getCode()) pattern, we need to ensure that the function returns an integer. This change adds an explicit type conversion to a Python integer in the wrapper code. Change-Id: I73d6b881025064afa2b2e6eb4512fa2a4b0a87da Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jose Marinho <jose.marinho@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-on: https://gem5-review.googlesource.com/4280 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Joe Gross <joe.gross@amd.com>
2017-05-24python: Fix PyEvent reference counting bugAndreas Sandberg
The current implementation of reference counting for PyEvents only partially works. The native object is currently kept alive while it is in the event queue. However, if the Python object goes out of scope, the Python side of this object is garbage collected which leaves a "dangling" native object. This results in confusing error messages where PyBind is unable to find the Python implementation of an event when it is triggered. Implement reference counting using the generalized reference counting API instead. Change-Id: I4e8e04abc4f61dff238d718065f5371e73b38ab3 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-on: https://gem5-review.googlesource.com/3222 Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-05-22python: Prevent Python wrappers from deleting SimObjectsAndreas Sandberg
The PyBind wrappers could potentially delete SimObjects if they don't have any references. This is not desirable since there could be pointers to such objects within the C++ world. This problem doesn't normally occur since Python typically holds a pointer to the root node as long as the simulator is running. Prevent SimObject and Param deletion by using a PyBind-prescribed unique_ptr with a dummy deleter as the pointer wrapper for the Python world. Change-Id: Ied14602c9ee69a083a69c5dae1b5fcf8efb4548a Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-on: https://gem5-review.googlesource.com/3224 Reviewed-by: Gabe Black <gabeblack@google.com>
2017-05-22python: Fix weird memory issue in wrapped AddrRange vectorsAndreas Sandberg
There is a weird issue with the PyBind wrapper of vector<AddrRange>. Assigning new values to a param that is a vector of AddrRange sometimes results in an out-of-bounds memory access. We work around this issue by treating AddrRange vectors as opaque types. This slightly changes the semantics of the wrapper since Python now manipulates the real object rather than a copy that has been converted to a list. Change-Id: Ie027c06e7a7262214b43b19a76b24fe4b20426c5 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-by: Timothy Hayes <timothy.hayes@arm.com> Reviewed-on: https://gem5-review.googlesource.com/3223 Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-05-09misc: Expose the listener loopbackOnly function to python.Gabe Black
Change-Id: Ibb405af54a46a93706a6f476b5314491e84be0c8 Reviewed-on: https://gem5-review.googlesource.com/3081 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2017-05-02python: Remove SWIGAndreas Sandberg
Remove SWIG-specific Python code. Change-Id: If1d1b253d84021c9a8f9a64027ea7a94f2336dff Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2922 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
2017-05-02python: Use PyBind11 instead of SWIG for Python wrappersAndreas Sandberg
Use the PyBind11 wrapping infrastructure instead of SWIG to generate wrappers for functionality that needs to be exported to Python. This has several benefits: * PyBind11 can be redistributed with gem5, which means that we have full control of the version used. This avoid a large number of hard-to-debug SWIG issues we have seen in the past. * PyBind11 doesn't rely on a custom C++ parser, instead it relies on wrappers being explicitly declared in C++. The leads to slightly more boiler-plate code in manually created wrappers, but doesn't doesn't increase the overall code size. A big benefit is that this avoids strange compilation errors when SWIG doesn't understand modern language features. * Unlike SWIG, there is no risk that the wrapper code incorporates incorrect type casts (this has happened on numerous occasions in the past) since these will result in compile-time errors. As a part of this change, the mechanism to define exported methods has been redesigned slightly. New methods can be exported either by declaring them in the SimObject declaration and decorating them with the cxxMethod decorator or by adding an instance of PyBindMethod/PyBindProperty to the cxx_exports class variable. The decorator has the added benefit of making it possible to add a docstring and naming the method's parameters. The new wrappers have the following known issues: * Global events can't be memory managed correctly. This was the case in SWIG as well. Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Andrew Bardsley <andrew.bardsley@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2231 Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com> Reviewed-by: Pierre-Yves PĂ©neau <pierre-yves.peneau@lirmm.fr> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>