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

Rafael EspĂ­ndola via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 1 15:32:25 PDT 2016

On 1 June 2016 at 15:21, 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). 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.

Please don't, reproducible builds are *really* important.

Note that you can disable build-id with -Wl,--build-id=none.

Maybe make the default an even simpler hash? Or hash just parts of the file?

I would also be open to just changing clang to not pass --build-id by default.


More information about the llvm-dev mailing list