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

[David Blaikie via llvm-commits]

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

> gold is about 10% slower with --build-id to link Clang. So "okay" is
> stricter than that.
>

It may be unrealistic given the design of the feature, to get much better?
(may not be, perhaps there's something about gold's architecture or just
its design of the feature that's poor)

Is it worth considering a different feature to achieve the underlying goal
that might be more efficient to implement? (what is the goal of --build-id?
what does it do/provide?)


>
> On Thu, Mar 10, 2016 at 12:14 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
>
>> 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.
>>
>> On Thu, Mar 10, 2016 at 11:23 AM, Rui Ueyama via llvm-commits <
>> llvm-commits at lists.llvm.org> wrote:
>>
>>> ruiu created this revision.
>>> ruiu added reviewers: rafael, emaste.
>>> ruiu added a subscriber: llvm-commits.
>>>
>>> This is not ready for submission.
>>>
>>> This patch implements --build-id in a naive way. After the linker creates
>>> an output file in the memory buffer, it computes the md5sum of the
>>> resulting
>>> file and set the hash to the .note section as a build-id.
>>>
>>> The problem is that its performance impact is too large. Computing a
>>> secure
>>> hash is a computational intensive task (our md5sum function seems a bit
>>> too
>>> slow, though). Here are some numbers (milliseconds to link):
>>>
>>> LLD:     713.78 ->  883.44 (+23.8%)
>>> Scylla: 5005.64 -> 5437.84 (+8.6%)
>>>
>>> Even if we replace MD5 with a faster hash function, it cannot be within
>>> an "okay" range, which is, say, +3%.
>>>
>>> Do you guys have any opnion on this? I have a few ideas.
>>>
>>>  - Use CRC32 instead of MD5. Non-secure hash should be much faster.
>>>
>>>  - 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.
>>>
>>>  - 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.
>>>
>>>  - 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.)
>>>
>>>  - Do not support build-id and let the user pass --build-id=<hash value>.
>>>
>>> http://reviews.llvm.org/D18055
>>>
>>> Files:
>>>   ELF/Config.h
>>>   ELF/Driver.cpp
>>>   ELF/Options.td
>>>   ELF/OutputSections.cpp
>>>   ELF/OutputSections.h
>>>   ELF/Writer.cpp
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160310/1b72811e/attachment.html>