> On Sept. 17, 2015, 6:38 p.m., Steve Reinhardt wrote: > > I've had the same problem with the absolute vs. relative path thing, and > > had just been working around it by specifying an absolute path on the > > command line. Nice to have a real fix for this, but I'm not convinced by > > it :).
Thanks for the pointers. The updated patch addresses both - hopefully more convincing. > On Sept. 17, 2015, 6:38 p.m., Steve Reinhardt wrote: > > src/sim/syscall_emul.cc, line 426 > > <http://reviews.gem5.org/r/3106/diff/1/?file=49288#file49288line426> > > > > don't you really want to get an absolute path here though? the > > comment makes it sound like this isn't a complete solution. should we be > > calling realpath() on the return value from fullPath()? Do we even want to > > call fullPath(), since we're not using the stored cwd when we open the > > binary in LiveProcess::create()? Sweet, yes! I thought there was a name for it other than "full" or "absolute" path, but had trouble finding it. - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3106/#review7208 ----------------------------------------------------------- On Sept. 17, 2015, 7:47 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3106/ > ----------------------------------------------------------- > > (Updated Sept. 17, 2015, 7:47 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11092:fba06d1c46b0 > --------------------------- > 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
