search for: linkingcontext

...wrote: > >> Hi, >> >> It is needed that lld verifies the input to the linker. >> >> For example : a x86 ELF file can be given to lld when the target is >> x86_64. Similiarly with other flavors. >> >> I was thinking to have a varargs function in the LinkingContext that would >> be overridden by each of the LinkingContexts to verify files after being >> read. >> >> The reader would call the varargs function in the LinkingContext and raise >> an error if the input is not suitable with the current link mode. >> >> Thank...

Hi, It is needed that lld verifies the input to the linker. For example : a x86 ELF file can be given to lld when the target is x86_64. Similiarly with other flavors. I was thinking to have a varargs function in the LinkingContext that would be overridden by each of the LinkingContexts to verify files after being read. The reader would call the varargs function in the LinkingContext and raise an error if the input is not suitable with the current link mode. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc....

...;>> >>> It is needed that lld verifies the input to the linker. >>> >>> For example : a x86 ELF file can be given to lld when the target is >>> x86_64. Similiarly with other flavors. >>> >>> I was thinking to have a varargs function in the LinkingContext that >>> would >>> be overridden by each of the LinkingContexts to verify files after being >>> read. >>> >>> The reader would call the varargs function in the LinkingContext and >>> raise >>> an error if the input is not suitable with...

...<shankare at codeaurora.org> wrote: >> It is needed that lld verifies the input to the linker. >> >> For example : a x86 ELF file can be given to lld when the target is x86_64. Similiarly with other flavors. >> >> I was thinking to have a varargs function in the LinkingContext that would be overridden by each of the LinkingContexts to verify files after being read. >> >> The reader would call the varargs function in the LinkingContext and raise an error if the input is not suitable with the current link mode. > Yes. We need a way to error out if there is...

...n <shankare at codeaurora.org>wrote: > Hi, > > It is needed that lld verifies the input to the linker. > > For example : a x86 ELF file can be given to lld when the target is > x86_64. Similiarly with other flavors. > > I was thinking to have a varargs function in the LinkingContext that would > be overridden by each of the LinkingContexts to verify files after being > read. > > The reader would call the varargs function in the LinkingContext and raise > an error if the input is not suitable with the current link mode. > > Thanks > > Shankar Easwaran...

...efault/user driven option. The Gnu linker has the following options :- --demangle=[style] --no-demangle I found that clang/llvm-symbolizer use __cxx_demangle function. I would think that lld also need to call the same function, and I think the way we want to demangle is to have the function in LinkingContext as various flavors may choose to use different API's to demangle symbol names. The API's that would be in LinkingContext would be :- * virtual bool canDemangle() = 0; // Does the flavor provide a way to demangle symbol names ? * virtual std::string demangle(StringRef...

..., Shankar Easwaran <shankare at codeaurora.org> wrote: > It is needed that lld verifies the input to the linker. > > For example : a x86 ELF file can be given to lld when the target is x86_64. Similiarly with other flavors. > > I was thinking to have a varargs function in the LinkingContext that would be overridden by each of the LinkingContexts to verify files after being read. > > The reader would call the varargs function in the LinkingContext and raise an error if the input is not suitable with the current link mode. Yes. We need a way to error out if there is an architec...

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

...hat models Readers, do we want to have a > function in the Registry that evaluates whether a file should be parsed > into atoms (or) raise an appropriate error ? > > I would think the output architecture could be chosen from the first file > that was parsed, I think each flavor's LinkingContext should store a field > pointing to the architecture of the first input file that was tried to be > parsed. > > Thanks > > Shankar Easwaran > > > On 10/7/2013 3:50 PM, Shankar Easwaran wrote: > >> On 10/7/2013 3:23 PM, Nick Kledzik wrote: >> >>> On...

...kar 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 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...

So is for PE32 and PE32+. They cannot be mixed because they are for x86 and x86-64, respectively. I'd think we can simply wait for all files to be parsed and pass them to a LinkingContext to ask whether or not the input file set seems OK. On Tue, Apr 1, 2014 at 9:59 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 4/1/2014 11:51 PM, Simon Atanasyan wrote: > >> On Wed, Apr 2, 2014 at 7:47 AM, Shankar Easwaran >> <shankare at codeaurora.org&gt...

...g options :- >> >> --demangle=[style] >> --no-demangle >> >> I found that clang/llvm-symbolizer use __cxx_demangle function. >> >> I would think that lld also need to call the same function, and I think the way we want to demangle is to have the function in LinkingContext as various flavors may choose to use different API's to demangle symbol names. >> >> The API's that would be in LinkingContext would be :- >> >> * virtual bool canDemangle() = 0; // Does the flavor provide a way to demangle symbol names ? >> *...

...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 file if the current node is not a group node >>>> b) Returns the next file in the group node,...

...d. Is all that needed? I think all the InputGraph needs to know is if the last file was used. A group is scanned repeatedly until there is one complete pass in which no new files were used. Also, is nextFile() going to be in InputGraph and directly accessed by the Resolver? Or is nextFile in LinkingContext (which forwards it to the InputGraph)? I assume the later. Currently, the Resolver has buildInitialAtomList() and resolveUndefines() which matches the way darwin links. I assume part of this change is to unify those two methods by just have one loop that uses nextFile(). Given that nextFile() i...

...he input graph directly, for we don't want to implement the details of input graph control node behavior for --{start,end}-group, -z rescan{,-now}, or whatever you define as a new linker option. Implementing it to Resolver would make it messy. 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 until nextFile() returns a null value. 3. Resolver will notify Linking Context when (A) all undefined sy...

...ri, 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, 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 until nextFile() returns a null value. >> >> 3. Resolver will notify Linking Context when (A...

...ibrary depends on the ReaderWriter/Native library, which links against the ReaderWriter library, which links against the Core library. This clearly cannot work. The same cycle exists with Core -> YAML -> ReaderWrite -> Core. The situation seems a bit worse for includes. If you start from LinkingContext.h I think this becomes quite clear. This is ostensibly part of the Core library, but it has methods that produce types from the ReaderWriter library. Combined with the fact that ReaderWriter depends on Core (not the other way around) and ReaderWriter/ELF subclasses LinkingContext, I can't make...

...gt;>> 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 file if the current node is not a group node >>>>> b) Returns the next...

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 handle the input graph at all. Instead, Resolver calls nextFile() repeatedly to link until nextFile() returns a null value. >> >> 3. Resolver will notify Linking Context when (A)...

...between sub-directories in ReaderWriter. > That would be nice. Can you sketch out what this would look like? The other issue is that while the above makes sense to me, if you look at the #include lines in these libraries, it is *very* far from the truth. How do we fix this? In particular, the LinkingContext seems to establish a lot of circular dependencies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150120/a18dc6b7/attachment.html>