> On Sept. 28, 2015, 8:39 a.m., Andreas Hansson wrote: > > src/dev/x86/intdev.hh, line 150 > > <http://reviews.gem5.org/r/3117/diff/2/?file=50024#file50024line150> > > > > This is fine, but what about just making it purely virtual?
As proposed in the latest patch, this allows us to inherit in the I8259 device without needing to explicitly override it there. Sure, pure virtual would require overriding the function before a new device will compile rather than hitting the panic during simulation. However, given recvResponse() is currently only used in I82094AA, I don't yet see a need for it to be explicitly defined in other devices. > On Sept. 28, 2015, 8:39 a.m., Andreas Hansson wrote: > > src/dev/x86/i82094aa.hh, line 108 > > <http://reviews.gem5.org/r/3117/diff/2/?file=50022#file50022line108> > > > > override Can you clarify? This declaration overrides the virtual declaration in IntDevice, and I don't expect anyone will want to inherit from I82094AA. Am I missing something? - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3117/#review7296 ----------------------------------------------------------- On Sept. 27, 2015, 7:52 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3117/ > ----------------------------------------------------------- > > (Updated Sept. 27, 2015, 7:52 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11145:b92a7a451890 > --------------------------- > arch, x86: Delete packet in IntDevice::recvResponse > > IntDevice::recvResponse is called from two places in current mainline: (1) the > short circuit path of X86ISA::IntDevice::IntMasterPort::sendMessage for atomic > mode, and (2) the full request->response path to and from the x86 interrupts > device (finally called from MessageMasterPort::recvTimingResp). In the former > case, the packet was deleted correctly, but in the latter case, the packet and > request leak. To fix the leak, move request and packet deletion into IntDevice > inherited class implementations of recvResponse. > > > Diffs > ----- > > src/dev/x86/i82094aa.hh bd894d2bdd7c > src/dev/x86/i82094aa.cc bd894d2bdd7c > src/dev/x86/intdev.hh bd894d2bdd7c > src/dev/x86/intdev.cc bd894d2bdd7c > > Diff: http://reviews.gem5.org/r/3117/diff/ > > > Testing > ------- > > Compiled gem5.debug with --without-tcmalloc. Ran x86 FS tests with Valgrind. > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
