similar to: [LLVMdev] [lld]Native reader/writer is not called, treated as Dead Code!

On Sep 23, 2013, at 10:02 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > When changes were brought from lld core to the Universal Driver, calls to NativeReader/NativeWriter code was stripped away. This needs to be fixed. Originally, ever run of the linker would have a step were it wrote to native and read that back in. That makes sense for test cases,

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 > > to lld::DefinedAtom? That seems good to me. We just need to figure out > what should happen with atoms not

Hi Nick, Can we add a atomContentHash for DefinedAtoms when the atoms are being created. This can essentially speed up comparisons of atoms especially for * ICF (Identical code folding) * Section groups (to identify similiar sections) Not sure where else this would help. This would essentially be used only by the Reader and the Resolver. There would be no change to the

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

On May 7, 2013, at 10:38 PM, Michael Spencer <bigcheesegs at gmail.com> 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 > > to

On 10/4/2013 11:16 PM, Michael Spencer wrote: > On Fri, Oct 4, 2013 at 8:50 PM, Shankar Easwaran <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

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

On 10/7/2013 3:23 PM, Nick Kledzik wrote: > On Oct 4, 2013, at 8:50 PM, 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

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

On Sun, Oct 6, 2013 at 7:38 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/4/2013 11:16 PM, Michael Spencer wrote: > >> On Fri, Oct 4, 2013 at 8:50 PM, Shankar Easwaran <shankare at codeaurora.org >> >**wrote: >> >> Hi, >>> >>> It is needed that lld verifies the input to the linker. >>> >>> For example

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

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)

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

On Wed, Apr 2, 2014 at 7:47 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > I am not sure if you looked at this thread > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066155.html) > > let me know if you still have questions. > > As a short summary, we dont verify the architecture of files that are being > read. We could very well be passed in a

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

Ping ? Do you think that we need to have an API in LinkingContext to return the next ordinal available, so that files created by passes can be assigned ordinals ? Thanks Shankar Easwaran On 10/6/2013 11:07 PM, Shankar Easwaran wrote: > In addition I think the LayoutPass std::stable_sort be replaced with > std::sort as total ordering is guaranteed as each File would get an >

On Fri, Oct 4, 2013 at 8:50 PM, Shankar Easwaran <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

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