[PATCH] D18055: ELF: Implement --build-id.

[Rui Ueyama via llvm-commits]

On Thu, Mar 10, 2016 at 12:17 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> BTW, have you tried this in combination with the patch for using
> posix_memalign? Since this basically reads back the output of the
> linker I would be curious if that patch makes any difference is the
> results.


My gut is that accessing a mmap'd memory region linearly is very fast
anyway, but let me try.


> >  - Use CRC32 instead of MD5. Non-secure hash should be much faster.
>
> That is a bit too weak I think, but we can block this on getting a
> better MD5 or use another strong but fast hash.
>
> >  - Make clang to calculate a secure hash for each section.
> >    This is basically moving the workload from the linker to the compiler,
> >    but we can use the hash for ICF in the linker,
> >    so it might be a overall win.
>
> Seems like something we should do in the future, but should not depend
> on it. That is, having the hash available speeds up build-id, but
> build-id should work without it.
>
> >  - Compute a build-id from input files' timestamps. This makes builds
> >    non-reproducible if you touch a file, so I don't think we want this.
>
> Not this. O use of build-id is for checking for reproducible builds I
> think.
>
> >  - Build-id is not needed for program execution in general.
> >    So we may be able to let the linker exit as soon as it's done with
> linking,
> >    and backfill the hash value in a background process which is kicked in
> >    by the linker. (It's probably unrealistic plan, though.)
>
> A bit dangerous I would say.
>
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160310/73cc9190/attachment.html>