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

Ed Maste via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 11 09:37:27 PST 2016


On 11 March 2016 at 11:56, Rui Ueyama <ruiu at google.com> wrote:
> Non-secure hash function such as FNV1 can be written in 10 lines of code or
> so, so we don't necessarily have to use ADT/Hashing.h.
>
> The question is whether we need to use a secure hash or not. If we can
> accept a collision of build ID (although it's a very low probability), we
> should use a non-secure hash. If not, we need to use a secure hash. It seems
> to me that everybody's basically okay with a very low probability of
> collision for the sake of performance? So here's my plan.
>
>  - Use a fast non-secure hash function as default for --build-id
>  - Implement --build-id=md5 (GNU ld and gold both have this option) so that
> users can choose the secure hash function
>
> Any objections/concerns?

This sounds broadly fine to me.

Note that ld.bfd and gold support md5, sha1, and a 128-bit random
number ("uuid"). sha1 seems to be the default for both ld.bfd and
gold, and if we implement only one "secure" hash I think that should
be it.

Gold also has a mode that parallelizes by hashing chunks of the output
file, and then hashing those hashes. It's unfortunate to expose so
many options to the user though. I'm not sure what makes the most
sense for us with respect to providing useful knobs, and bfd/gold
compatibility. In my ideal world we'd have only one option in lld
that's both fast and secure.

One other item to consider, some tools make expectations about the
size of the build-id data. For example, "file" uses the size to report
the putative algorithm used. It reports "sha1" for a 20-byte build-id
and "md5/uuid" for a 16-byte build-id.

% cc -fuse-ld=gold -Wl,--build-id hello.c
% file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 10.1
(1001507), BuildID[sha1]=74c58ef86747a092d357a42cc106eb4688e15333, not
stripped
%

In any case I'd be happy with what you describe above, but with a
small preference for sha1 over md5.


More information about the llvm-commits mailing list