similar to: [LLVMdev] [lld] contentHash in the Reader ?

Shankar, Do you mean add a method like: virtual unsigned contentHash() const = 0; or maybe: virtual llvm::hash_code contentHash() const = 0 to lld::DefinedAtom? That seems good to me. We just need to figure out what should happen with atoms not intended to be merged. Should the method assert? In the case where we want there to be a hash available, is it computed lazily?

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 > > to lld::DefinedAtom? That seems good to me. We just need to figure out > what should happen with atoms not

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

On May 7, 2013, at 10:38 PM, Michael Spencer <bigcheesegs at gmail.com> 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 > > to

Hi Nick, When changes were brought from lld core to the Universal Driver, calls to NativeReader/NativeWriter code was stripped away. Was this by accident ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

On Sep 23, 2013, at 10:02 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > When changes were brought from lld core to the Universal Driver, calls to NativeReader/NativeWriter code was stripped away. This needs to be fixed. Originally, ever run of the linker would have a step were it wrote to native and read that back in. That makes sense for test cases,

Hi Nick, Thanks for your reply. The usecase here is just trying to construct a valid ELF. The lld linker needs to handle all sorts of code written in assembly as well as 'C'. The usecase is just one example of it. I have also seen similiar code in http://lxr.free-electrons.com/source/arch/powerpc/kernel/head_32.S?a=powerpc which has global and local labels. You are right, that the

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;

On 5/8/2013 2:45 PM, Nick Kledzik wrote: > > I'd rather we use a crypto hash so we don't have to compare content at all. > The crypto hashes work well if the atom content is const data (e.g. c-string or other literals), since you just point the hash function at the range of bytes in the constant data. Where it gets messier is if you are trying to coalesce non-leaf functions or

Hi Nick, Waiting for your feedback on this. Thanks Shankar Easwaran On 11/16/2012 10:03 AM, Shankar Easwaran wrote: > Hi Nick, > > Thanks for your reply. > > The usecase here is just trying to construct a valid ELF. The lld > linker needs to handle all sorts of code written in assembly as well > as 'C'. The usecase is just one example of it. > > I have also

On Wed, May 8, 2013 at 10:29 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > 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

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

On Wed, May 8, 2013 at 7:33 PM, Rui Ueyama <ruiu at google.com> wrote: > On Wed, May 8, 2013 at 10:29 AM, Shankar Easwaran <shankare at codeaurora.org > > wrote: > >> On 5/8/2013 11:35 AM, Chandler Carruth wrote: >> >>> Interestingly newer, supposedly "more secure" digest algorithms are also >>> very often significantly faster. I

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

On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> wrote: > > What are the SHA-3 variants that you think would suite these needs ? > > I want to look at the implementation complexity. The winner (and the official SHA3 algorithm), BMW and Skein are all worth looking at. If your primary criterion is through-put on large, desktop-class CPUs, Skein is likely

On Wed, May 8, 2013 at 9:13 PM, Owen Anderson <resistor at mac.com> wrote: > On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > >> >>> What are the SHA-3 variants that you think would suite these needs ? >> >> > I want to look at the implementation complexity. The winner (and the > official SHA3 algorithm),

Hi Nick, On 9/20/2013 5:59 PM, Nick Kledzik wrote: > On Sep 20, 2013, at 3:42 PM, Shankar Easwaran > <shankare at codeaurora.org> wrote: >> nextFile could pass the current resolver state at the time when its called, the linkingcontext can return the next file to be processed as below :- >> >> nextFile(currentResolverState) :- >> >> a) Returns the next

My email client spoilt the whole email, will create a pdf and send it. On 9/20/2013 7:00 PM, Shankar Easwaran wrote: > Hi Nick, > > On 9/20/2013 5:59 PM, Nick Kledzik wrote: >> On Sep 20, 2013, at 3:42 PM, Shankar Easwaran >> <shankare at codeaurora.org> wrote: >>> nextFile could pass the current resolver state at the time when its >>> called, the

On Sep 20, 2013, at 3:37 PM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Sep 20, 2013 at 3:29 PM, Nick Kledzik <kledzik at apple.com> wrote: > Rui, > > I like this in general, but have a few questions. > > On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote: > >> 2. We would instead add a new method nextFile() to LinkingContext,

On Sep 16, 2013, at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Michael, > On 9/16/2013 7:23 PM, Michael Spencer wrote: >> Debug info linking is currently broken due to how we handle reading and >> laying out non SHF_ALLOC sections. I posted a patch that partially fixes >> this, but it's both the wrong approach and doesn't handle