[llvm-dev] LLD's default --build-id choice
Rui Ueyama via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 1 15:41:08 PDT 2016
On Wed, Jun 1, 2016 at 3:32 PM, Rafael Espíndola <rafael.espindola at gmail.com
> 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
> > --build-id was the right one or not.
> > Currently, we compute a FNV1 hash for an entire resulting file and store
> > to .note.gnu.build-id section. It's one of the slowest parts of the
> > because reading every byte takes time. IIRC, it usually takes about 10%
> > 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
> > done in 2009). Build ID is sometimes useful, particularly when
> > 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
> > have been added that casually.
> > Anyways, the option is there and passed to the linker, so we have to
> > and add a build ID if --build-id option is given (we could ignore the
> > 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
I think FNV1 is very fast hash function, so we cannot make it faster by
replacing it with some other hash function.
We could hash only some part of the file, say the first page of an
executable. In that way, there's a risk that two executables with the same
build ID are actually different if they have idential ELF headers, but is
it going to be a problem?
> I would also be open to just changing clang to not pass --build-id by
I'd be very happy if we do it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev