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

[Ed Maste via llvm-commits]

On 10 March 2016 at 15:20, David Blaikie <dblaikie at gmail.com> wrote:
>
> 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?)

There's a good description of it here:
https://fedoraproject.org/wiki/Releases/FeatureBuildId

There are three uses that I'm aware of:

1. Identifying the original binary from a core dump. The build-id
makes it to the core file, and the debugger needs only the core dump
as an argument.
2. Validating separate debug info (GNU debuglink) for
binaries/libraries. The debugger can compare the build-id in the
binary and debug file and confirm that the debug file matches.
Otherwise it does a CRC32 of each debug file on each invocation.
3. Locating the separate debug files, e.g. in /usr/lib/debug/<build-id>.

Basically it needs to be a reproducible, unique identifier for the
binary or library.

On 10 March 2016 at 15:17, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>
>>  - 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.

This will produce a different build-id, of course, but that's fine.

> Also, hashing each input section as it is copied out might be more
> cache friendly.

Yes, hashing as we go is preferable to a single pass over everything at the end.