|
From: Julian S. <js...@ac...> - 2005-11-08 00:50:30
|
Euh, ok. Try r5033. The idea of readlink("/proc/self/exe") is pretty
good, but there are systems on which /proc/self/exe is borked. So I
fell back to what is essentially your original plan.
J
On Sunday 06 November 2005 14:23, Jeroen N. Witmond wrote:
> >> 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.
|