similar to: [LLVMdev] LLD input graph handling proposal

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 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, Attached is the pdf of the operation to make things easier to read. Thanks Shankar Easwaran On 9/20/2013 7:04 PM, Shankar Easwaran wrote: > 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, I think your proposal and mine are pretty much the same. The difference is passing back info to the InputGraph as a parameter in nextFile() vs as a separate method call. My original draft email had a parameter in nextFile(), but it seemed a little confusing because the information was referring to the previous file. That is, if the current resolver state has newDefinedAtoms, that

Hi Nick, Read this along with this example extract: ld -flavor gnu main.o thread.o --start-group libc.a libpthread.a --end-group function.o main.o has atoms ------------------------ main (defined) printf(undefined) fn(undefined) thread.o has atoms ----------------------------- pthread_create (undefined) libc.a(printf.o) has atoms ------------------------------------ printf(defined)

Hi Nick, On 9/20/2013 5:29 PM, Nick Kledzik 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, which returns a new file from which Resolver should try to resolve undefined symbols. Resolver wouldn't

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, which returns a new file from which Resolver should try to resolve undefined symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver calls nextFile() repeatedly to link

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, >> 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 the problem I have is each flavor has extra command line options >> for which it wants to create a DefinedAtom/UndefinedAtom. The flavor also may want to add extra linker internal files in

On Fri, Sep 20, 2013 at 3:59 PM, Nick Kledzik <kledzik at apple.com> wrote: > > 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

Hi Nick, On 8/28/2013 6:37 PM, Nick Kledzik wrote > $cat 1.c > int _start() { return 0; } > $gcc -c 1.c > $ld -u myundef 1.o > ==> Does not throw any error, the resolver was hinted that myundef was a undefined weak symbol. > Wow. Reading the gnu ld man page, that is not obvious. How can you make a non-weak undefined on the command line? That is, how can you force and error

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

Hi, Right now, linker added symbols specified by the -u option do not endup in the output YAML file. This is because the target specific Writers dont get called, which creates the undefined atoms. I am in the process of adding more options and I would like the atoms created internally by the options available in the output YAML file. The options that I am trying to consider for the linker

On Aug 28, 2013, at 4:24 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > >> Also for the case of -u, the Driver can make generic UndefinedAtoms. > ELF would want to treat the undefined symbols as a weak undefined symbols. So the driver cant create undefined atoms. > > Below is an example :- > > $cat 1.c > int _start() { return 0; }

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

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 Fri, Sep 20, 2013 at 04:39:04PM -0700, Rui Ueyama wrote: > I don't want to make Resolver to have a reference to input graph. The point > of this proposal is to separate input graph handling from Resolver and > instead making Linker Context to do that task. That was the part of the original proposal I didn't agree with and I still don't do. While the resolver shouldn't

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