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