Searched hist:12035 (Results 1 - 5 of 5) sorted by relevance
/gem5/src/python/pybind11/ | ||
H A D | core.hh | 12035:7b8e1b36875d Wed May 10 08:16:00 EDT 2017 Andreas Sandberg <andreas.sandberg@arm.com> python: Fix weird memory issue in wrapped AddrRange vectors 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> |
H A D | core.cc | diff 12035:7b8e1b36875d Wed May 10 08:16:00 EDT 2017 Andreas Sandberg <andreas.sandberg@arm.com> python: Fix weird memory issue in wrapped AddrRange vectors 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> |
/gem5/src/systemc/core/ | ||
H A D | object.hh | diff 12984:02f20eeeb8ce Thu Jul 19 20:12:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Make orphans top level objects instead of panic-ing. When a simulation ends, the sc_objects it contains are destroyed one by one, not necessarily in hierarchy order. That means that a parent object can legitimately be destroyed before its children. Instead of panic-ing when that inevitably happens, this change makes gem5 turn those children into top level objects. Change-Id: Icad9c99310fbc3ddcadbbb4f8a990b4fbfe35bdf Reviewed-on: https://gem5-review.googlesource.com/12035 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | object.cc | diff 12984:02f20eeeb8ce Thu Jul 19 20:12:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Make orphans top level objects instead of panic-ing. When a simulation ends, the sc_objects it contains are destroyed one by one, not necessarily in hierarchy order. That means that a parent object can legitimately be destroyed before its children. Instead of panic-ing when that inevitably happens, this change makes gem5 turn those children into top level objects. Change-Id: Icad9c99310fbc3ddcadbbb4f8a990b4fbfe35bdf Reviewed-on: https://gem5-review.googlesource.com/12035 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
/gem5/src/python/m5/ | ||
H A D | SimObject.py | diff 12035:7b8e1b36875d Wed May 10 08:16:00 EDT 2017 Andreas Sandberg <andreas.sandberg@arm.com> python: Fix weird memory issue in wrapped AddrRange vectors 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> |
Completed in 43 milliseconds