----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3106/#review7208 -----------------------------------------------------------
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 :). src/sim/process.cc (line 533) <http://reviews.gem5.org/r/3106/#comment6122> why not just reassign params->executable here? then we could get rid of the redundant test in the constructor above src/sim/syscall_emul.cc (line 426) <http://reviews.gem5.org/r/3106/#comment6123> 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()? - Steve Reinhardt On Sept. 12, 2015, 5:33 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3106/ > ----------------------------------------------------------- > > (Updated Sept. 12, 2015, 5:33 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11092:03dde9f9798c > --------------------------- > 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/syscall_emul.cc 62e1504b9c64 > src/sim/process.hh 62e1504b9c64 > src/sim/process.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
