> On Sept. 22, 2015, 9:02 a.m., Tony Gutierrez wrote: > > src/sim/syscall_emul.cc, line 420 > > <http://reviews.gem5.org/r/3106/diff/4/?file=49854#file49854line420> > > > > This comment is inaccurate, and therefore may lead to some confusion. > > There is no non-determinism, apparent or otherwise. I think 2) is > > sufficient to describe the problem. > > > > If you do want to add a TODO it should probably simply say that this > > code should be revisited once an FS redirection scheme is in place, the > > lack of which is causing the real problem.
I agree with Tony---this is really just an example of host state leaking into the simulation, which happens in other ways in SE execution as well (often to do with the filesystem). As we mentioned on the list, we have some patches that implement a basic path redirection scheme that should give people the tools to make files appear to gem5 at the same path even if they're at different paths on the host. We hope to get those posted as soon as we get past some internal deadlines, probably in a few weeks. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3106/#review7246 ----------------------------------------------------------- On Sept. 20, 2015, 10:06 a.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3106/ > ----------------------------------------------------------- > > (Updated Sept. 20, 2015, 10:06 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11092:3f4435aa225e > --------------------------- > syscall_emul: Bandage readlink /proc/self/exe > > The recent changeset to readlink() to handle reading the /proc/self/exe link > introduces a number of problems. This patch fixes two: > > 1) Because readlink() called on /proc/self/exe now uses > LiveProcess::progName() > to find the binary path, it will only get the zeroth parameter of the > simulated > system command line. However, if a config script also specifies the process' > executable, the executable parameter is used to create the LiveProcess rather > than the zeroth command line parameter. Thus, the zeroth command line > parameter > is not necessarily the correct path to the binary executing in the simulated > system. To fix this, add a LiveProcess data member, 'executable', which is > correctly set during instantiation and returned from progName(). > > 2) If a config script allows a user to pass a relative path as the zeroth > simulated system command line parameter or process executable, readlink() will > incorrecly return a relative path when called on '/proc/self/exe'. > /proc/self/exe is always set to a full path, so running benchmarks can fail if > a relative path is returned. To fix this, clean up the handling of > LiveProcess::progName() within readlink() to get the full binary path. > > NOTE: This patch still leaves the potential problem that host full path to the > binary bleeds into the simulated system, potentially causing apparent > non-deterministic simulated system execution. > > > Diffs > ----- > > src/sim/process.hh 62e1504b9c64 > src/sim/process.cc 62e1504b9c64 > src/sim/syscall_emul.cc 62e1504b9c64 > > Diff: http://reviews.gem5.org/r/3106/diff/ > > > Testing > ------- > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
