On Thu, May 9, 2013 at 12:04 AM, Shankar Easwaran <shankare at codeaurora.org>wrote:> On 5/8/2013 12:38 AM, Michael Spencer wrote: > >> On Tue, May 7, 2013 at 10:08 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> Shankar, >>> >>> Do you mean add a method like: >>> >>> virtual unsigned contentHash() const = 0; >>> >>> or maybe: >>> >>> virtual llvm::hash_code contentHash() const = 0 >>> >> We could use a crypto hash too with the function prototype that looks > like :- > > virtual lld::crypto::sha256 contentHash() const = 0I'd use SHA128 or MD5 as the linker does not handle hostile input. I think as long as it's collision free, it should suffice. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130509/9ff353fa/attachment.html>
On Wed, May 8, 2013 at 6:03 PM, Rui Ueyama <ruiu at google.com> wrote:> I'd use SHA128 or MD5 as the linker does not handle hostile input. I think > as long as it's collision free, it should suffice.FWIW, the need for a collision free hash -- or *digest*, my preferred term -- is well known. Interestingly newer, supposedly "more secure" digest algorithms are also very often significantly faster. I don't think we want any of the ones mentioned here, I think we want one of the candidates is the SHA3 competition which had truly stellar software implementation throughput. I'm hoping to add support for such a digest algorithm to LLVM soon, as there are many folks who want to consume this information: modules, merge function pass, debug info, and the linker. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/38ab37a0/attachment.html>
On 5/8/2013 11:35 AM, Chandler Carruth wrote:> Interestingly newer, supposedly "more secure" digest algorithms are > also very often significantly faster. I don't think we want any of the > ones mentioned here, I think we want one of the candidates is the SHA3 > competition which had truly stellar software implementation > throughput. I'm hoping to add support for such a digest algorithm to > LLVM soon, as there are many folks who want to consume this > information: modules, merge function pass, debug info, and the linker.Nice, Is it performant in size as well as speed too ?. Because lld would need to store this information for every atom thats mergeable. What are the SHA-3 variants that you think would suite these needs ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation