Quoting nathan binkert <n...@binkert.org>: >>> What redirection? Or do you mean because traceData is protected in >>> the simple CPU? You could, but then again, you could just make it >>> public. Otherwise, I'm not sure what you're talking about. The >>> execute function is generated for each cpu model separately and it >>> knows the type. >> >> I'm talking about how there's the exec context, and then the proxy >> exec context, and the thread context, and the simple thread context, >> and the dyninst, and the etc. etc., and calls to, for instance, read a >> register can travel through several layers before actually being >> serviced. By making traceData a direct member of the very first exec >> context interface, we're precluding passing it back to other layers >> that may want some input. That's not to say I don't think it will >> work, because I actually think it would, but it seems inconsistent >> with how the rest of that interface goes together. > I'm specifically talking about the parameter passed into the exec > function which is either SimpleCPU or BaseDynInst. Those both have a > traceData parameter and it can just be used directly without any fancy > indirection. I am only talking about this code specifically.
I'm confused now. If we're passing it in, then it's a local variable on the stack and we can't set it to NULL externally. If it's a local member of the exec context, it's not transparently modifiable by deeper layers of the interface. If it's a function call, we're paying a bunch of function call overhead. Which of these do (do not) apply? > >> Also this still doesn't address the fact that, one, completeAcc is >> being called before initiateAcc has fully run, and two, that the trace >> information is being printed before initiateAcc has written all its >> results. > Can't we just ensure that foo->traceData is set to NULL after it is > deleted? Then the setData that's done in initiateAcc after the write > won't complete. > > Also, looking at the code more closely, is there some reason taht we > can't just move the setData line before the write? Wouldn't that > solve the problem? It seems to me that the program wouldn't change > since the contents of Mem should not change due to xc->write? > (correct?) > > Sorry if I'm just being unhelpful. I don't know this code super well. That would ideally fix the segfault, aka the symptom, but it doesn't fix the core issue. The second half of initiateAcc won't be able to participate in the trace since traceData is dumped right before being deleted. That portion will also actually run -after- completeAcc, but only sometimes. That sounds like a source for a lot of confusion and bugs (like this one) to me. As far as moving around the code, that would be easier said than done. That's all generated and I don't know how easy it would be to get the isa_parser to generate something structured differently that would still make sense in all the other instructions of all the other ISAs. Steve? _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
