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

[Ed Maste via llvm-commits]

emaste added a comment.

I think crc32 is a nonstarter: we probably don't need all of the attributes of a cryptographically secure hash, we do want to avoid collisions and I don't think crc32 is sufficient. Off hand I'd suggest we might want to try blake2b (https://blake2.net/). Timestamps are no good due to collisions and nonreproducibility.

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


This is a pretty neat idea, and we can easily combine those hashes into the output build-id value. We'd have to come up with an appropriate way to store those hashes though.

I was thinking about an approach of post-filling build-id in FreeBSD, because we'd like --build-id and it's not supported in GNU ld 2.17.50 that we have in the base system. We'd provide a dummy space for a build-id note e.g. in csu, and give objcopy the ability to fill that in. But I agree that it doesn't make a lot of sense in the context of a feature to add to lld.

> Do not support build-id and let the user pass --build-id=<hash value>.


bfd and gold both allow a hash value to be specified directly and it seems reasonable to support that mode even when some other hashing is implemented.

All of that said, I think something like blake2 is not too far off -- my 4 year old desktop uses 1.6 CPU seconds to hash a 1GB random file. We can also look at a threaded model for hash calculation.

In any case, a straightforward (but optimized) approach in lld is going to be no worse than invoking a separate tool to calculate and store the hash, and for my use case that's fine. Is it that unreasonable to pay the cost if the user specifies --build-id, and it's off by default for the regular edit-compile-test cycle?


http://reviews.llvm.org/D18055