similar to: [LLVMdev] defining symbols with lld

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 composed of other symbols. > Any symbol that appears in the expression, gets its value

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

On Fri, Aug 23, 2013 at 4:54 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Nick, > > Thanks for your reply. > > > On 8/23/2013 3:40 PM, Nick Kledzik wrote: > >> >> These are the changes I plan to make, and some questions that I have >> >> a) Define a new contentType for DefinedAtoms to say 'Expression' >> b) Create a

Hi Nick, Thanks for your reply. On 8/23/2013 3:40 PM, Nick Kledzik wrote: > > These are the changes I plan to make, and some questions that I have > > a) Define a new contentType for DefinedAtoms to say 'Expression' > b) Create a new class ExprnAtom derived from DefinedAtom > c) The expression could also contain various functions that could be set in the expression, how

On Aug 22, 2013, at 6:42 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 8/22/2013 3:44 PM, Nick Kledzik wrote: >> >> Linker scripts have the same need. My idea for this was to allow atoms to have an associated expression tree and would have references to all symbols in that tree. The resolver wouldn't need any special handling for this, and the backend

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

On 8/22/2013 3:44 PM, Nick Kledzik wrote: > > Linker scripts have the same need. My idea for this was to allow atoms to have an associated expression tree and would have references to all symbols in that tree. The resolver wouldn't need any special handling for this, and the backend would just need to evaluate the expression at the end. > Agreed. > > On one hand, this sounds

On Sep 13, 2013, at 3:35 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > This would work only if an alias is another name for the same symbol(weak symbols). I don’t know what that means. Can you clarify? > > If what is being aliased is another function definition, which is a non zero sized atom, aliasing will not work. That is the exact scenario I think it *will* work

On Aug 23, 2013, at 1:54 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > Thanks for your reply. > > On 8/23/2013 3:40 PM, Nick Kledzik wrote: >> >> These are the changes I plan to make, and some questions that I have >> >> a) Define a new contentType for DefinedAtoms to say 'Expression' >> b) Create a new class

Can an “alias” atom just be a zero sized atom with one reference of kindLayoutBefore to its target? The layout engine should then place the alias atom right before the real atom, so you wind up with two symbols at one address. -Nick On Sep 12, 2013, at 3:02 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > In addition to what you mentioned, I think there

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

Hi Nick, On 8/27/2013 12:45 AM, Nick Kledzik wrote: > On Aug 26, 2013, at 10:20 PM, Shankar Easwaran wrote: >> Can we add deadStrip() to undefinedAtoms as well ? >> >> This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them. >> >> Also I think it will be cleaner for atoms to be added to deadStripRoot set using a

On Thu, Aug 22, 2013 at 6:42 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > These are the changes I plan to make, and some questions that I have > > a) Define a new contentType for DefinedAtoms to say 'Expression' b) Create a new class ExprnAtom derived from DefinedAtom > c) The expression could also contain various functions that could be set > in the

On 9/13/2013 6:06 PM, Nick Kledzik wrote: > On Sep 13, 2013, at 3:35 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: >> This would work only if an alias is another name for the same symbol(weak symbols). > I don’t know what that means. Can you clarify? Doesnt this imply that the alias atom is a zero sized atom ? >> If what is being aliased is another function

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

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,

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 Wed, Jan 2, 2013 at 12:04 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > You might want to look at the ELFLayout changes to see what functionality is > missing from that. > > The ELFLayoutOptions has a hook into reading the Linker script which needs > to be implemented. So, looking into it a bit, I think that ELFLayoutOptions is not the right place to parse the