|
From: Jeroen N. W. <jn...@xs...> - 2005-11-06 14:24:04
|
> >> Forgive my ignorance, but why do you need to check the segment's file >> name >> at all? Now that V is one static executable, the only file to have >> SkFileV >> should be the V executable anyway. > > That's true, but I don't want to hardwire that assumption in. > > Anyway, what I suggested doesn't work, because argv[0] can be a > relative pathname, whereas the names in the NSegments are always > absolute paths. > > I just committed the change Nick suggested (r5020) which should allow > reading from in-place builds too. However, since I don't know how to > run the system in-place (I never do so myself) I haven't test it - can > you try? This change does not work, because the name constructed by coregrind/launcher.c to execve the tool is a symbolic link, which is resolved to the real name before it appears in /proc/self/maps. This real name does not contain the string '.in_place/'. The attached patch is a hack that solves both the relative file name problem and the symbolic link problem, without assuming that Valgrind is a single static module. It works for me, it does not break the regression test; but it probably is not a real fix, because of violations of the modularization of Valgrind. It's beyond me to fix that. :-) Jeroen. |