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

[Gabor Greif]

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.

Cheers,

	Gabor

PS: removed llvm-commits from the CC: list.

> 
> - Ben
> 
>> Here is the patch:
>>
>>
>>
>> Index: autoconf/configure.ac
>> ===================================================================
>> --- autoconf/configure.ac       (revision 160127)
>> +++ autoconf/configure.ac       (working copy)
>> @@ -647,6 +647,20 @@
>> AC_DEFINE_UNQUOTED([ENABLE_TIMESTAMPS],$ENABLE_TIMESTAMPS,
>>                    [Define if timestamp information (e.g., __DATE__) is allowed])
>>
>> +dnl Enable reading of the "/proc/self/exe" link.
>> +AC_ARG_ENABLE(proc-self-exe,
>> +  AS_HELP_STRING([--enable-proc-self-exe],
>> +                 [Enable reading of the "/proc/self/exe" link (default is YES)]),,
>> +                 enableval=default)
>> +case "$enableval" in
>> +  yes) AC_SUBST(ENABLE_PROC_SELF_EXE,[1]) ;;
>> +  no)  AC_SUBST(ENABLE_PROC_SELF_EXE,[0]) ;;
>> +  default) AC_SUBST(ENABLE_PROC_SELF_EXE,[1]) ;;
>> +  *) AC_MSG_ERROR([Invalid setting for --enable-proc-self-exe. Use "yes" or "no"]) ;;
>> +esac
>> +AC_DEFINE_UNQUOTED([ENABLE_PROC_SELF_EXE],$ENABLE_PROC_SELF_EXE,
>> +                   [Define if reading of the "/proc/self/exe" link is allowed])
>> +
>> dnl Allow specific targets to be specified for building (or not)
>> TARGETS_TO_BUILD=""
>> AC_ARG_ENABLE([targets],AS_HELP_STRING([--enable-targets],
>>
>>
>> I'll commit after a LGTM.
>>
>> However before tweaking lib/Support/Unix/Path.inc I have to add a cmake
>> modification, which can be simply <always on>. Hints how to do this are
>> welcome, but I guess I'll figure it out.
>>
>> So what do you think?
>>
>> Cheers,
>>
>> 	Gabor
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>