search for: linkingcontexts

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

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. is a member of Code Aurora Forum, hosted by the Linux Fou...

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

...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 architecture mismatch. But there are some interestin...

...t; 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. is a memb...

Hi Nick, Bigcheese, When lld is used to link C++ code, it would be required to demangle symbol names by default/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

...rote: > 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 architecture mismatch. But there are some interesting scenarios...

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

...gt; >>>> 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 err...

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

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 4/2/2014 12:23 PM, Nick Kledzik wrote: > On Apr 1, 2014, at 9:19 PM, Shankar Easwaran wrote: > >> Hi Nick, Bigcheese, >> >> When lld is used to link C++ code, it would be required to demangle symbol names by default/user driven option. >> >> The Gnu linker has the following options :- >> >> --demangle=[style] >> --no-demangle >>

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

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

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,

I wanted to go through and map out the layering of LLD's libraries today and found that it's essentially impossible. I think some serious cleanup is needed here. Let's start with the purely link-level dependencies encoded in the CMake build: Curently the Core library depends on the ReaderWriter/Native library, which links against the ReaderWriter library, which links against the Core

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

On Tue, Jan 20, 2015 at 6:06 PM, Rui Ueyama <ruiu at google.com> wrote: > On Tue, Jan 20, 2015 at 5:42 PM, Chandler Carruth <chandlerc at google.com> > wrote: > >> >> On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >>> On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> >>>