similar to: [LLVMdev] Chaining Atoms together

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

Hi Nick, Can we add a atomContentHash for DefinedAtoms when the atoms are being created. This can essentially speed up comparisons of atoms especially for * ICF (Identical code folding) * Section groups (to identify similiar sections) Not sure where else this would help. This would essentially be used only by the Reader and the Resolver. There would be no change to the

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?

Hi Nick, Dead stripping optimization needs a way to setup the roots which are live. The current code in Resolver does it by 1) setting all the global defined atoms to be the live set when building shared libraries (_options.allGlobalsAreDeadStripRoots) 2) Or, uses a list of names that are dead strip roots (other types) Question:- *********** How are the dead strip root names supposed to be

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 multiple input files with debug info (wrong relocation values). The first issue is representing non SHF_ALLOC atoms in the Atom model. We currently don't have a type for this, and

Hi Nick, In addition to what you mentioned, I think there needs a special *AliasReference* that need to be created which the DefinedAtom points to. Thanks Shankar Easwaran -------- Original Message -------- Subject: Re: [PATCH] Add a fallback mechanism for undefined atom. Date: Thu, 29 Aug 2013 15:15:49 -0700 From: kledzik at apple.com <kledzik at apple.com> Reply-To:

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 multiple input > files with debug info (wrong relocation values). > > The first issue is representing non

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

I guess I'm talking about atoms. Do we have notion of section in LLD? On Wed, Mar 25, 2015 at 8:35 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 3/24/2015 7:51 PM, Rui Ueyama wrote: > >> On Tue, Mar 24, 2015 at 5:40 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> On Mar 24, 2015, at 5:09 PM, Rui Ueyama <ruiu at google.com>

Hi Nick, We have few symbols like __bss_start, __bss_end, which are Undefined symbols in the code. I want a way in the Reader to create specific atoms before the linker bootstraps. I didnt find a way to do that with the existing interfaces. The way it needs to work is as below :- 1) ReaderELF creates Absolute symbols (for __bss_start, __bss_end etc) 2) ReaderELF reads each file and adds

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

Can we remove Native format support? I'd like to get input from anyone who wants to keep the current Native format in LLD. On Thu, Feb 5, 2015 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > The only way currently is to create a new reference, unless we can think > of adding some target specific metadata information in the Atom model. > > This has come up

I'm not planning to remove YAML. YAML is important for testing. On Fri, Feb 6, 2015 at 3:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > I am fine with it. I hope you are not planning to remove YAML. > > > On 2/6/2015 4:54 PM, Rui Ueyama wrote: > > Can we remove Native format support? I'd like to get input from anyone who > wants to keep the

On Aug 22, 2013, at 1:32 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Thu, Aug 22, 2013 at 12:54 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > I am planning to work on adding support for definining expressions for the Gnu flavor. > > Currently Gnu ld supports an option --defsym symbol=expression. The expression may be

Hi Nick, This would work only if an alias is another name for the same symbol(weak symbols). If what is being aliased is another function definition, which is a non zero sized atom, aliasing will not work. I was thinking to model this for ELF for the below functionalities :- a) __wrap For example : --wrap fn What I plan to do here is, create a undefined function fn atom create a defined

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 Oct 30, 2012, at 7:53 PM, Shankar Easwaran wrote: > Hi Nick, >> Can you be more specific in your proposal. What method(s) would you add to the the Atom class(es)? I thought you were thinking of a generic uint32_t DefinedAtom::flags() method where the meaning of each bit in the uint32_t returned was platform specific. How can that work with a min/max range? >> > The range

On Dec 7, 2012, at 11:51 AM, Shankar Easwaran wrote: > We have few symbols like __bss_start, __bss_end, which are Undefined symbols in the code. > > I want a way in the Reader to create specific atoms before the linker bootstraps. > > I didnt find a way to do that with the existing interfaces. > > The way it needs to work is as below :- > > 1) ReaderELF creates

Thanks for the reply Nick. I will use the Writer::addFiles functionality. Do you want to move the SimpleFile class to lld/Core ? It might be useful for other types of object files too(like for ELF here). How does typeFirstInSection/typeLastinSection know that the addresses that need to be used for those symbols are the symbol values for the section start / section end ? I didnt see