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

[Rui Ueyama via llvm-commits]

On Thu, Mar 10, 2016 at 12:25 PM, Rui Ueyama <ruiu at google.com> wrote:

> 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.
>

The patch to use posix_memalign was slightly negative. It took 893.88
milliseconds to link LLD.


>> >  - 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/f0f9e90c/attachment.html>