similar to: [LLVMdev] [lld] process undefined atoms from shared library only once

I'd do that with the nextFile abstraction like this: On the first iteration, a Group would return its member every time getNextFile() is called (the same as the current behavior). On the second and further iterations, the Group should skip all the members whose type is not Archive. By doing this, the core linker sees dynamic libraries (or regular object files) only once even if they are in

Hi Rui, I thought about this, but there is a catch. The undefined symbols still need to be resolved with exports from dynamic libraries even the second time, or any number of times. For example :- ld 1.o --start-group libc.so myprintf.a --end-group 1.o has a undef for myprintf, which is in myprintf.a and myprintf.a calls puts. The first time when libc.so, undef atoms would be added, no

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,

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

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

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,

Shankar and I discussed input file handling, and we came up with a design that may greatly simplify the input file handling, while giving more flexibility to developer to support complicated options, such as --{start,end}-group, -z rescan or -z rescan-now. It'd worth pursuing, so here's the idea: 1. We wouldn't probably want to let Resolver to handle the input graph directly, for we

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

Hi, 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 single API. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

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

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

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 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 single API. Can you give more more background on this? When would you want

Currently, member functions like File::defined() return an iterator for const atoms. But we don't actually treat atoms as consts -- we updates atoms in many places including the core resolver. We have too many const_casts in our code. It just doesn't make sense. I'm making a change to make atoms non-const. Please hit reply if you have any concerns. -------------- next part

Hi Nick, I need the original path of the files, from where the atoms were parsed. The path for the atoms are completely useless after the round trip pass. This is needed to support linker scripts with the Gnu flavor. I think there are more uses too like diagnostics (relocation overflows etc) I was planning to add a patch so that the native writer, stores the original path for atoms Another

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, It looks like the COFF reader creates an Alias atom by adding a kindLayoutAfter reference to the target atom. Now since the kindLayoutAfter passes are moved to machO how does it still work ? Does it work by chance because of ordinals ? I would think moving kindLayoutAfter references and having the LayoutPass would be a better choice. Shankar Easwaran -- Qualcomm Innovation Center,

On 30 June 2014 16:16, Shankar Easwaran <shankare at codeaurora.org> wrote: > I think you are hitting a bug, the Observer pattern was added a few weeks > back, and may be there is some sort of uninitialized variable ? This is my back-trace at "-O2 -g" (since -O1 pass): operator() (file=<optimized out>, __closure=0x7fffffffde40) at