summaryrefslogtreecommitdiff
path: root/util/tap/Makefile
diff options
context:
space:
mode:
authorAndreas Sandberg <andreas.sandberg@arm.com>2017-03-28 13:50:06 +0000
committerAndreas Sandberg <andreas.sandberg@arm.com>2017-04-03 16:38:26 +0000
commit31199bba53493bcfb4d130d8c739d698d21b5dd5 (patch)
treeea3d3a24ee0575f1a7098f7fddb90552c194f353 /util/tap/Makefile
parent9a13acaa367769c38859342de9bc35aac59a6710 (diff)
downloadgem5-31199bba53493bcfb4d130d8c739d698d21b5dd5.tar.xz
sim: Handle cases where Drainable::resume() creates objects
There are cases where Drainable objects need to create new objects in Drainable::resume(). In such cases, the local drain state will be inherited from the DrainManager. We currently set the state to Running as soon as we start resuming the simulator. This means that new objects are created in the Running state rather than the Drained state, which the resume code assumes. Depending on the traversal order in DrainManager::resume(), this sometimes triggers a panic because the object being resumed is in the wrong state. This change introduces a new drain state, Resuming, that the DrainManager enters as soon as it starts resuming the simulator. Objects that are created while resuming are created in this state. Such objects are then resumed in a subsequent pass over the list of Drainable objects that need to be resumed. Once all objects have been resumed, the simulator enters the Running state. Change-Id: Ieee8645351ffbdec477e9cd2ff86fc795e459617 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2600 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Weiping Liao <weipingliao@google.com>
Diffstat (limited to 'util/tap/Makefile')
0 files changed, 0 insertions, 0 deletions