similar to: [LLVMdev] Advanced Command line processing with lld

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)

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

Sent from my iPhone On Mar 9, 2013, at 1:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 3/8/2013 5:44 PM, Nick Kledzik wrote: >> On Mar 8, 2013, at 2:52 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: >>> Hi Nick, >>> >>> I was looking at ld64 source code and the atom deals with additional information such as

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

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?

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

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

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 5/8/2013 12:38 AM, Michael Spencer wrote: > 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 We could use a crypto hash too

So I talked with Shankar on IRC on this topic, and here's a suggestion. 1. Use a magic comment to determine if it's a YAML file. I'd propose "#!obj" as a YAML file magic because of similarity of Unix shebang. YAML reader skips this first line because it's a comment line in YAML grammar. 2. Add "target" field to YAML to represent what machine type the object

On 10/9/2013 4:19 PM, Shankar Easwaran wrote: > On 10/9/2013 3:09 PM, Nick Kledzik wrote: >> On Oct 9, 2013, at 11:23 AM, Shankar Easwaran >> <shankare at codeaurora.org> wrote: >>> We have a whole bunch of readers(we would have some more too), and >>> was thinking if we should have a vector of Readers, and have a >>> function isMyFormat in each

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

On Wed, Oct 9, 2013 at 7:57 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/9/2013 4:19 PM, Shankar Easwaran wrote: > >> On 10/9/2013 3:09 PM, Nick Kledzik wrote: >> >>> On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org> >>> wrote: >>> >>>> We have a whole bunch of readers(we would have

Could you elaborate a bit about the issue that you are trying to solve with this suggestion? On Tue, Apr 1, 2014 at 9:27 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Nick, Bigcheese, > > Resurrecting a old thread. > > Now since we have a Registry that models Readers, do we want to have a > function in the Registry that evaluates whether a file should be

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

Ah Sorry. Totally forgot about that. On 10/10/2013 8:24 PM, Rui Ueyama wrote: > # is a line comment chracter in YAML so it's valid. That's why I wrote a > simple magic "comment". > > > On Thu, Oct 10, 2013 at 6:21 PM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> On 10/10/2013 5:00 PM, Rui Ueyama wrote: >> >>> On Thu,

On 10/14/2013 8:20 PM, Sean Silva wrote: > On Mon, Oct 14, 2013 at 8:41 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > >> On Wed, Oct 9, 2013 at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org >>> wrote: >>> Hi, >>> >>> We have a whole bunch of readers(we would have some more too), and was >>> thinking if we should

Here at CERT we've written some prototype tools that use YAML files to hold a minimal subset of the Clang parse tree. We then combine these files to perform cross-TU static analysis. We write out *only* the minimal information required for the particular static analysis being performed, so it's a tiny subset of the entire parse tree. Of course, that's all a hack-around to enable the