search for: currentresolverst

Displaying 10 results from an estimated 10 matches for "currentresolverst".

2013 Sep 20
1
[LLVMdev] LLD input graph handling proposal
...re being fulfilled by a,b,c,a,b,c…, but how does the resolver know that the files are repeating, to know to tell the InputGraph to move on? 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 file if the current node is not a group node b) Returns the next file in the group node, if the current node is a group node and the resolver state states undefined /weak / shared library atoms were added. c) Returns the start file in the group node, if the resolver st...
2013 Sep 21
2
[LLVMdev] LLD input graph handling proposal
...>>> <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 file if the current node is not a group node >>>> b) Returns the next file in the group node, if the current node is >>>> a group node and the resolver state states undefined /weak / shared >>>> libra...
2013 Sep 20
0
[LLVMdev] LLD input graph handling proposal
...he group provided any more content. 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 file if the current node is not a group node > b) Returns the next file in the group node, if the current node is a group node and the resolver state states undefined /weak / shared library atoms were added. > c) Returns the start file in the group node,...
2013 Sep 21
2
[LLVMdev] LLD input graph handling proposal
...k 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 file if the current node is not a group node >> b) Returns the next file in the group node, if the current node is a group node and the resolver state states undefined /weak / shared library atoms were added. >> c) Returns the start file in t...
2013 Sep 21
0
[LLVMdev] LLD input graph handling proposal
...ankare 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 file if the current node is not a group node >>>>> b) Returns the next file in the group node, if the current node is >>>>> a group node and the resolver state states undefined /weak / >>>&...
2013 Sep 20
6
[LLVMdev] LLD input graph handling proposal
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
2013 Sep 21
0
[LLVMdev] LLD input graph handling proposal
...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 file if the current node is not a group node >>> b) Returns the next file in the group node, if the current node is a >>> group node and the resolver state states undefined /weak / shared >>> library atoms were added....
2013 Sep 20
0
[LLVMdev] LLD input graph handling proposal
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
2013 Sep 21
1
[LLVMdev] LLD input graph handling proposal
...2 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 file if the current node is not a group node >>>>>> b) Returns the next file in the group node, if the current node is a group node and the resolver state states undefined /weak / shared library atoms...
2013 Sep 20
3
[LLVMdev] LLD input graph handling proposal
...ent. > > > 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 file if the current node is not a group node > b) Returns the next file in the group node, if the current node is a group > node and the resolver state states undefined /weak / shared library atoms > were added. > c) Returns the start file in the gro...