Searched hist:12035 (Results 1 - 5 of 5) sorted by relevance

/gem5/src/python/pybind11/
H A Dcore.hh12035: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 Dcore.ccdiff 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 Dobject.hhdiff 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 Dobject.ccdiff 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 DSimObject.pydiff 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