<div dir="ltr">gold is about 10% slower with --build-id to link Clang. So "okay" is stricter than that.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 10, 2016 at 12:14 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Do you have a sense of how other linkers implement this feature and/or how much it costs in performance/link time? You mention what an "okay" cost for this would be, but it's not clear to me how you determined that cost.<br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Mar 10, 2016 at 11:23 AM, Rui Ueyama via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">ruiu created this revision.<br>
ruiu added reviewers: rafael, emaste.<br>
ruiu added a subscriber: llvm-commits.<br>
<br>
This is not ready for submission.<br>
<br>
This patch implements --build-id in a naive way. After the linker creates<br>
an output file in the memory buffer, it computes the md5sum of the resulting<br>
file and set the hash to the .note section as a build-id.<br>
<br>
The problem is that its performance impact is too large. Computing a secure<br>
hash is a computational intensive task (our md5sum function seems a bit too<br>
slow, though). Here are some numbers (milliseconds to link):<br>
<br>
LLD: 713.78 -> 883.44 (+23.8%)<br>
Scylla: 5005.64 -> 5437.84 (+8.6%)<br>
<br>
Even if we replace MD5 with a faster hash function, it cannot be within<br>
an "okay" range, which is, say, +3%.<br>
<br>
Do you guys have any opnion on this? I have a few ideas.<br>
<br>
- Use CRC32 instead of MD5. Non-secure hash should be much faster.<br>
<br>
- Make clang to calculate a secure hash for each section.<br>
This is basically moving the workload from the linker to the compiler,<br>
but we can use the hash for ICF in the linker,<br>
so it might be a overall win.<br>
<br>
- Compute a build-id from input files' timestamps. This makes builds<br>
non-reproducible if you touch a file, so I don't think we want this.<br>
<br>
- Build-id is not needed for program execution in general.<br>
So we may be able to let the linker exit as soon as it's done with linking,<br>
and backfill the hash value in a background process which is kicked in<br>
by the linker. (It's probably unrealistic plan, though.)<br>
<br>
- Do not support build-id and let the user pass --build-id=<hash value>.<br>
<br>
<a href="http://reviews.llvm.org/D18055" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18055</a><br>
<br>
Files:<br>
ELF/Config.h<br>
ELF/Driver.cpp<br>
ELF/Options.td<br>
ELF/OutputSections.cpp<br>
ELF/OutputSections.h<br>
ELF/Writer.cpp<br>
<br>
<br></div></div>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>