> On Sept. 22, 2015, 4:02 p.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.
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**
- Joel
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3106/#review7246
-----------------------------------------------------------
On Sept. 20, 2015, 5:06 p.m., Joel Hestness wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3106/
> -----------------------------------------------------------
>
> (Updated Sept. 20, 2015, 5:06 p.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
