similar to: [LLVMdev] [lld] Atom object model refactoring.

On Jul 18, 2012, at 3:41 PM, Clow, Marshall wrote: > On Jul 18, 2012, at 2:34 PM, Nick Kledzik wrote: >> On Jul 18, 2012, at 12:52 PM, Michael Spencer wrote: >>> I've run into some issues with the current atom object model that I >>> would like to fix. >>> >>> The current 4 atoms are not expressive enough. We need to be able to >>>

On 9/23/2013 7:07 PM, Nick Kledzik wrote: > On Sep 23, 2013, at 4:52 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. >> >> #include <stdio.h> >> >> int main() { >> fputs("hi\n", stdout); >>

The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. #include <stdio.h> int main() { fputs("hi\n", stdout); } The reason is that stdout gets a R_X86_64_PC32 relocation, but is of type Object. The ELF writer can't see this, and assumes all R_X86_64_PC32 relocations in dynamic outputs are to functions

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:

On Sep 23, 2013, at 4:52 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. > > #include <stdio.h> > > int main() { > fputs("hi\n", stdout); > } > > The reason is that stdout gets a R_X86_64_PC32 relocation, but is

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, The problem is when the -emit-yaml option is used, the writer is set to the YAML writer. The YAML writer doesnot have anything to add here. The problem can be solved by having the YAML writer append a list of undefined atoms specified by the -u option, but the problem I have is each flavor has extra command line options for which it wants to create a DefinedAtom/UndefinedAtom. The

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 Oct 30, 2012, at 11:10 AM, Shankar Easwaran wrote: >>> >>> 3) How are you planning to support Atom specific flags ? Is there a way already ? >>> (This would be needed to group similiar atoms together) >> It is still an open question how to support platform specific Atom attributes. As much as possible we'd like to expand the Atom model to be a superset

On Aug 28, 2013, at 3:14 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > The problem is when the -emit-yaml option is used, the writer is set to the YAML writer. Ah! > > The YAML writer does not have anything to add here. > > The problem can be solved by having the YAML writer append a list of undefined atoms specified by the -u option, but

On Sep 23, 2013, at 7:05 PM, Shankar Easwaran wrote: > On 9/23/2013 7:07 PM, Nick Kledzik wrote: >> On Sep 23, 2013, at 4:52 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: >> >>> The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. >>> >>> #include <stdio.h>

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

Thanks for the reply Nick. 1) Is there a way to validate that the input file is of a valid format, thats defined by the YAML Reader ? > Do you mean different than if the yaml reader accepts it? Tons of > files will be valid yaml syntactically. It is the semantic level > checking that is hard, and that is what YAML I/O does. > Yes, if the YAML reader accepts it and figures out that

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, Thanks for your reply. How about if the atom flags could be overridden ? The Atom flag could have a MIN/MAX and anything above the MAX or lower than the MIN are platform specific, like how its dealt with section indexes ? > I know ELF file format has some ranges for various values that are specifically reserved for processors or "user" defined functionality. It serves 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 Oct 30, 2012, at 7:12 AM, Shankar Easwaran wrote: > Hi Nick, > > I had a few questions :- > > 1) Is there a way to validate that the input file is of a valid format, thats defined by the YAML Reader ? Do you mean different than if the yaml reader accepts it? Tons of files will be valid yaml syntactically. It is the semantic level checking that is hard, and that is what

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

Shankar, The LinkingContext has a addImplictFiles() method that is supposed to call the Writer and give it a chance to add any implicit files. Is the problem that the -u atoms are not attached to that implicit file? Or that the implicit file is not getting added? Or that this got lost in the transition from InputFiles to InputGraph? -Nick On Aug 28, 2013, at 2:44 PM, Shankar Easwaran

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