llvm dev - Jun 2016 - LLD's default --build-id choice

On Wed, Jun 1, 2016 at 4:57 PM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Wed, Jun 01, 2016 at 03:21:08PM -0700, Rui Ueyama via llvm-dev wrote:
> > In the first place, I believe it was not a good decision to make GCC
(and
> > therefore Clang) to pass --build-id option to the linker by default
(it
> was
> > done in 2009
<https://lists.debian.org/debian-gcc/2009/07/msg00082.html
> >).
> > Build ID is sometimes useful, particularly when distributing linked
> objects
> > to users, but in most cases it is not needed. Spending 10% more time
on
> > usual build-link-debug cycle is a waste of time. It should not have
been
> > added that casually.
>
> I fully agree on this (not passing it down by default automatically),
> since it doesn't create a very useful key.
>
> > --build-id=uuid sets build-id to a random unique value. It's very
fast.
> > Instead, it breaks build reproducibility because every build has a
unique
> > build ID. But if you want build reproducibility, you can explicitly
pass
> > --build-id=sha1.
>
> I think this is worse than not doing anything at all. What about the
> hash tree options, those can at least be computed piecewise and
> concurrently?
>
We could but it only mitigate the issue. If the decision was wrong in the
first place, I want to fix it completely if it's not too late.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/7c37b40c/attachment.html>

On 1 June 2016 at 17:03, Rui Ueyama via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Wed, Jun 1, 2016 at 4:57 PM, Joerg Sonnenberger via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> On Wed, Jun 01, 2016 at 03:21:08PM -0700, Rui Ueyama via llvm-dev
wrote:
>> > In the first place, I believe it was not a good decision to make
GCC
>> > (and
>> > therefore Clang) to pass --build-id option to the linker by
default (it
>> > was
>> > done in 2009
>> >
<https://lists.debian.org/debian-gcc/2009/07/msg00082.html>).
>> > Build ID is sometimes useful, particularly when distributing
linked
>> > objects
>> > to users, but in most cases it is not needed. Spending 10% more
time on
>> > usual build-link-debug cycle is a waste of time. It should not
have been
>> > added that casually.
>>
>> I fully agree on this (not passing it down by default automatically),
>> since it doesn't create a very useful key.
>>
>> > --build-id=uuid sets build-id to a random unique value. It's
very fast.
>> > Instead, it breaks build reproducibility because every build has a
>> > unique
>> > build ID. But if you want build reproducibility, you can
explicitly pass
>> > --build-id=sha1.
>>
>> I think this is worse than not doing anything at all. What about the
>> hash tree options, those can at least be computed piecewise and
>> concurrently?
>
>
> We could but it only mitigate the issue. If the decision was wrong in the
> first place, I want to fix it completely if it's not too late.
It should be fine. I will try writing a clang patch.

Cheers,
Rafael

On Wed, Jun 01, 2016 at 05:03:22PM -0700, Rui Ueyama
wrote:
> > What about the hash tree options, those can at least be computed
> > piecewise and concurrently?
> >
> 
> We could but it only mitigate the issue. If the decision was wrong in the
> first place, I want to fix it completely if it's not too late.
Well, the hash tree option would always help, even for the cryptographic
checksums that are even slower.

Joerg

On Thu, Jun 2, 2016 at 9:55 AM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Wed, Jun 01, 2016 at 05:03:22PM -0700, Rui Ueyama wrote:
> > > What about the hash tree options, those can at least be computed
> > > piecewise and concurrently?
> > >
> >
> > We could but it only mitigate the issue. If the decision was wrong in
the
> > first place, I want to fix it completely if it's not too late.
>
> Well, the hash tree option would always help, even for the cryptographic
> checksums that are even slower.

It's not always. It disperses workloads to multiple cores, so it mitigates
the situation, but if a link occurs during a build and other cores are
still busy compiling other stuff, it doesn't help.

> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/4ec7516d/attachment.html>