> 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. > > Steve Reinhardt wrote: > 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. > > Joel Hestness wrote: > I disagree with your assertion that this does not result in apparent > non-determinism; I spent a couple hours tracking down why gem5-gpu > regressions wouldn't pass immediately after I updated them. This most > certainly appeared as non-determinic/non-repeatable simulation. > > I think I'm ok with removing the TODO, but then I'd prefer that (2) be > more precise than being classified as "unexpected behavior". Would you mind > if I changed this to: > > // 2) The host's full path to the running benchmark changes from > one > // simulation to another. This can result in different > simulated > // performance since the simulated system will process the > binary > // path differently, **even if the binary does not change**
That looks good to me. I guess "apparent" is in the eye of the beholder :). - 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
