[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link

[Chandler Carruth]

On Fri, Jul 13, 2012 at 1:40 PM, Benjamin Kramer <benny.kra at gmail.com>wrote:

>
> On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com>
> wrote:
>
> > Benjamin Kramer wrote:
> >> On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com>
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I am in charge of the controlled introduction of clang into
> >>> our builds at my workplace. Since all our tools must run from
> >>> a ClearCase view for automatic dependency tracking, we have been
> >>> biten by a Linux bug, and readlink("/proc/self/exe", ...) gives
> >>> nonsensical results. So we need to introduce a configure option
> >>> for disallowing this method of executable discovery (the other
> >>> one works well).
> >>
> >> Interesting, can you describe the linux bug? Are the kernel devs aware
> of it?
> >
> > It is fixed in newer RHEL kernels (>=6). What I know is that this is a
> > ClearCase VFS-related bug that fails to do a reverse mapping to obtain
> > the logical pathname from the real (into the backing store of ClearCase)
> > one.
> >
> > Here is a bug report:
> > <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6189256>
> >
> >>
> >> We often had reports about /proc/self/exe not working (and thus clang
> crashing)
> >> in chrooted environments. It is possible to mount /proc into the chroot
> but this
> >> seems to be missing from many setups. The code in LLVM that uses
> /proc/self/exe
> >> returns an empty string on error which confuses clang.
> >
> > There is no empty string for me, and the returned string is a real object
> > (bytewise identical to the real thing) :
> >
> > $ cd <into a dynamic view>
> > $ cp /bin/ls .
> > $ ls -l /proc/self/exe
> > lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /bin/ls
> > $ ./ls -l /proc/self/exe
> > lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe ->
> /vol/ocs_userviews25_13/ggreif-hc_stm-OCSnb28718.vws/.s/00056/800006ba4fdf647els
> >
> > $ diff ./ls
> /vol/ocs_userviews25_13/ggreif-hc_stm-OCSnb28718.vws/.s/00056/800006ba4fdf647els
> > <no diffs>
> >
> > Unfortunately starting from the clang executable, there is no useful
> > directory structure to be discovered :-(
> >
> >>
> >> I don't really like having an autoconf switch for this as long as you
> can determine
> >> whether the result from /proc/self/exe is valid. When you're adding a
> fallback to
> >> Path.inc anyways, why not just try reading /proc/self/exe first, and if
> it fails, use
> >> your fallback? That would also fix the chroot problem.
> >
> > This is not a chroot problem. As shown above, I do not get a valid clang
> path
> > to manipulate and discover include directories, etc.
> >
> > The other method in lib/Support/Unix/Path.inc (i.e. dladdr, realpath)
> works.
> >
> > I still maintain that I need the configure option.
>
> Sorry for being mean, but this is a workaround for a bug in the linux
> kernel that was
> fixed years ago and is only visible when using an obscure revision control
> system.
>
> Also it requires rebuilding LLVM, so the fix isn't even helpful without
> researching the
> issue (if someone else hits it).
>
> With this in mind I really don't see why this has to be in the public
> tree, requiring
> additions to two build systems. Can't you just apply the one-line-patch to
> Path.inc
> locally?


I agree, this patch as is doesn't belong in the tree...

However, I suspect that Clang already hase the capability to solve this
problem for you.

For context, we run Clang in a distributed build environment not dissimilar
to the one you are describing, and for us as well /proc/self/exe does not
really help us locate the Clang binary. There is a switch available
(-no-canonical-prefixes) which in conjunction with some other things should
use the value of argv[0] in main to locate the clang binary, not
/proc/self/exe or anything else.

Can you describe why it is that Clang is reading /proc/self/exe? We might
be able to change that in a principled way to support numerous different
filesystem layouts and scenarios where its results are correct but not
helpful for locating executable-relative directory structures.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120713/6f7dba55/attachment.html>