[cfe-dev] icecream - what should /proc/cpuinfo contain on remote machines?

[Teresa Johnson via cfe-dev]

On Wed, May 10, 2017 at 1:01 PM, Reid Kleckner <rnk at google.com> wrote:

> This seems like an LLVM bug. I'd rather LLVM didn't look in /proc, but I
> can't find an alternative. In any case, we shouldn't print to stderr for a
> successful build. Silently falling back to std::thread::hardware_concurrency()
> seems fine, which is what the code does.
>

Agreed, we should at least return -1 if we can't find /proc/cpuinfo (which
will result in fallback to std::thread::hardware_concurrency()). The
question I have is whether it should be silent or not - my understanding
was that this file should exist in x86_64 Linux.

But I am also wondering how you hit this, since reading through the github
thread you linked indicated that this is not LTO or ThinLTO. Oh, I see now
where it is being used to initialize the value of an option...if this is a
file that will not always exist for Linux x86_64 then it needs to fall back
silently.

Teresa


> On Wed, May 10, 2017 at 12:21 PM, Miller Henry via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>>
>> Greetings, I’m the maintainer of icecream, and I’m trying to solve a bug
>> some of my users are seeing: when using clang  4.0 their build fails
>> because the file /proc/cpuinfo does not exist.  I’m trying to figure out
>> what the right solution to this is. See
>> *https://github.com/icecc/icecream/issues/176*
>> <https://github.com/icecc/icecream/issues/176>
>> From what we can tell this came in from:
>> *https://reviews.llvm.org/D25564* <https://reviews.llvm.org/D25564>.
>>
>> A summary for those who don’t want to read the above: icecream is a
>> distributed build tool that allows you to use other networked computers to
>> speed up your builds.  The local build machine where you run “make” ships
>> the compiler to remote machines which then run the compiler in a chroot
>> (this ensures that if the remote has a different version of clang installed
>> we do not use that).
>>
>> We see three options:
>>
>> Place an empty /proc/cpuinfo in the chroot. This seems to work and it is
>> easy.  From what we can tell this file is only used at link time and
>> icecream does not link on remote machines.  However if clang starts to use
>> /proc/cpuinfo for something else (asserts on valid contents) we are broke
>> again.
>>
>> When building the compiler package add /proc/cpuinfo from whatever
>> machine is building the environment.  /proc/cpuinfo may be bogus but at
>> least it exists. This is easy to do, but it is a coincidence if the file is
>> actually correct.
>>
>> Copy /proc/cpuinfo into the chroot on each build machine.  This is the
>> most difficult to implement (test), and I’m not sure if it gains anything
>> or not. Note in particular that icecream tries hard to use as many cores on
>> the remote machines as possible without the user of the remote machine
>> noticing a performance problem, thus clang using /proc/cpuinfo to spawn
>> additional threads is probably something we do not want.
>>
>> I’m leaning to the first because it is easy, but others have different
>> opinions. After looking at all the responses I’ve concluded that so far
>> nobody actually knows enough about what clang is doing (much less planning
>> to do) to make a useful decision.  Thus I’m reaching out to the clang
>> community: what considerations are we not aware of, and is there a good
>> reason to choose any plan?
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>


-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170510/12488f32/attachment.html>