[llvm-dev] LLD's default --build-id choice

Sean Silva via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 1 15:34:31 PDT 2016

Personally I don't like making things nondeterministic by default. I would
prefer to change clang to just not pass --build-id by default (or not by
default on -O0 or whatever).

-- Sean Silva

On Wed, Jun 1, 2016 at 3:21 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Nico brought up this topic and made me think whether the current choice of
> --build-id was the right one or not.
> Currently, we compute a FNV1 hash for an entire resulting file and store
> it to .note.gnu.build-id section. It's one of the slowest parts of the
> linker because reading every byte takes time. IIRC, it usually takes about
> 10% of total link time.
> 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.
> Anyways, the option is there and passed to the linker, so we have to
> create and add a build ID if --build-id option is given (we could ignore
> the option but that's probably very confusing.)
> So here's my proposal.
>  - Make --build-id=uuid as default for --build-id
> --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.
> _______________________________________________
> 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/20160601/b2f5a550/attachment.html>

More information about the llvm-dev mailing list