clang looking all over for linux libs [9.2 PRERELEASE]

[Roman Divacky]

Yes, this is because the FreeBSD driver toolchain shares the same
infrastructure with Linux. So we stat ~200 linux dirs :(

This rys.vlakno.cz/~rdivacky/freebsd-driver.patch proof of concept
patch fixes it by unsharing FreeBSD from Linux but I am not
convinced it's worth it.

It should also be possible to only stat those libs when -m32/-m64
is specified. That would be the preferred solution.

Roman

On Wed, Jul 17, 2013 at 04:13:41PM -0400, Kurt Lidl wrote:
> 
> I noticed this issue this morning, while looking at a unrelated
> compilation failure. I was using clang on an amd64 machine,
> running a system that corresponds closely to r253388.
> There are some local changes, but nothing with regards to the
> toolchain, except for removing GCC via the WITHOUT_GCC flag in src.conf.
> 
> lidl at nine0-135: cat hello.c
> #include <stdlib.h>
> #include <stdio.h>
> 
> int main(int argc, char *argv[])
> {
> 	printf("Hello world\n");
> 	return 0;
> }
> lidl at nine0-136: ktrace -i clang -c hello.c
> lidl at nine0-137: kdump |less
> [...]
>   74004 clang    CALL 
> open(0x7fffffffbf00,0x120004<O_NONBLOCK|O_DIRECTORY|O_CLOEXEC>,<unused>0x1d)
>   74004 clang    NAMI  "/usr/lib/gcc/x86_64-linux-gnu"
>   74004 clang    RET   open -1 errno 2 No such file or directory
>   74004 clang    CALL 
> open(0x7fffffffbf00,0x120004<O_NONBLOCK|O_DIRECTORY|O_CLOEXEC>,<unused>0x2e)
>   74004 clang    NAMI  "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu"
>   74004 clang    RET   open -1 errno 2 No such file or directory
> 
> My question is:  Why is the system compiler looking for all these
> directories that do not exist?
> 
> lidl at nine0-144: kdump |egrep -e NAMI -e /usr/lib | awk '{print $4}'
> [...]
> "/usr/lib/gcc/x86_64-linux-gnu"
> "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu"
> "/usr/lib/x86_64-linux-gnu"
> "/usr/lib/gcc/x86_64-unknown-linux-gnu"
> "/usr/lib/x86_64-unknown-linux-gnu/gcc/x86_64-unknown-linux-gnu"
> "/usr/lib/x86_64-unknown-linux-gnu"
> "/usr/lib/gcc/x86_64-pc-linux-gnu"
> "/usr/lib/x86_64-pc-linux-gnu/gcc/x86_64-pc-linux-gnu"
> "/usr/lib/x86_64-pc-linux-gnu"
> "/usr/lib/gcc/x86_64-redhat-linux6E"
> "/usr/lib/x86_64-redhat-linux6E/gcc/x86_64-redhat-linux6E"
> "/usr/lib/x86_64-redhat-linux6E"
> "/usr/lib/gcc/x86_64-redhat-linux"
> "/usr/lib/x86_64-redhat-linux/gcc/x86_64-redhat-linux"
> "/usr/lib/x86_64-redhat-linux"
> "/usr/lib/gcc/x86_64-suse-linux"
> "/usr/lib/x86_64-suse-linux/gcc/x86_64-suse-linux"
> "/usr/lib/x86_64-suse-linux"
> "/usr/lib/gcc/x86_64-manbo-linux-gnu"
> "/usr/lib/x86_64-manbo-linux-gnu/gcc/x86_64-manbo-linux-gnu"
> "/usr/lib/x86_64-manbo-linux-gnu"
> "/usr/lib/gcc/x86_64-linux-gnu"
> "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu"
> "/usr/lib/x86_64-linux-gnu"
> "/usr/lib/gcc/x86_64-slackware-linux"
> "/usr/lib/x86_64-slackware-linux/gcc/x86_64-slackware-linux"
> "/usr/lib/x86_64-slackware-linux"
> "/usr/lib/gcc/x86_64-unknown-freebsd9.2"
> "/usr/lib/x86_64-unknown-freebsd9.2/gcc/x86_64-unknown-freebsd9.2"
> "/usr/lib/x86_64-unknown-freebsd9.2"
> 
> It's actually a lot worse than this -- it also looks in /usr/lib32 for
> a different set of directories, and then again in /usr/lib
> for that diffferent set of libraries, and then in /usr/bin/../lib
> for the original set of directories and then again(!) in
> /usr/bin/../lib32 and /usr/bin/../lib for the second set of directories.
> 
> I would think, that as the configured system compiler, it wouldn't
> bother looking around for a bunch of stuff that it isn't going to
> find...  Sure, the data is in the buffer cache after the first run,
> but how about just not making several hundred useless system calls
> for each invocation of the compiler?
> 
> All this seems to come from:
> 	/usr/src/contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp
> 
> Is there something that can done to make this work better?
> 
> -Kurt
> 
> 
> 
> _______________________________________________
> freebsd-toolchain at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe at freebsd.org"