search for: elflinkingcontext

...from an old version of compiler-rt, which I did some work on last year. Like compiler-rt, I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and LLD_PATH_TO_LLVM_SOURCE. Any objection to that? Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp include a private header from the LLVM source tree, "llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the dependency on HAVE_CXXABI_H be removed? If no, mind if I add a config.h.cmake to LLD's "include/lld/Config"? Thanks, Greg

...> We wouldnt be able to override the functionality with each flavor, if we have a static method, or you had thought of something else ? I’m not sure when we would want polymorphism. If you wanted it in this case, there could be a method on LinkingContext to create a file of UndefinedAtoms, and ELFLinkingContext could override that method to make weak undefines. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130828/d2b2621e/attachment.html>

...We wouldnt be able to override the functionality with each flavor, if we have a static method, or you had thought of something else ? > I’m not sure when we would want polymorphism. If you wanted it in this case, there could be a method on LinkingContext to create a file of UndefinedAtoms, and ELFLinkingContext could override that method to make weak undefines. Yes this will work for undefined atoms that need to be supported by all flavors. All the implicit files that are needed would be added to a vector of files in the inputGraph, addImplicitFiles would splice/prepend to the list of input files which...

Hi Nick, >> 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 the problem I have is each flavor has extra command line options >> for which it wants to create a DefinedAtom/UndefinedAtom. The flavor also may want to add extra linker internal files in

...l resolver, and they are all special linker symbols. I propose two things. 1. Provide a hook as per what Shankar suggested for the resolver. User references to linker defined symbols such as _GLOBAL_OFFSET_TABLE_ get created and possibly deadstripped here. The linking context owns the atom. 2. The ELFLinkingContext gains <Atom *getOrCreateLinkerDefinedAtom(StringRef);>. This can be used in passes to get the symbols. The hook in (1) would call this to create the atoms. This gives a single place where linker defined atoms are actually created, and allows correct deadstripping and object file references w...

...special linker symbols. I propose two things. > > 1. Provide a hook as per what Shankar suggested for the resolver. User > references to linker defined symbols such as _GLOBAL_OFFSET_TABLE_ get > created and possibly deadstripped here. The linking context owns the > atom. > 2. The ELFLinkingContext gains <Atom > *getOrCreateLinkerDefinedAtom(StringRef);>. This can be used in passes > to get the symbols. The hook in (1) would call this to create the > atoms. > > This gives a single place where linker defined atoms are actually > created, and allows correct deadstripping...

...did some work on last year. Like compiler-rt, >> I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH >> instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and >> LLD_PATH_TO_LLVM_SOURCE. Any objection to that? >> >> Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp >> include a private header from the LLVM source tree, >> "llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the >> dependency on HAVE_CXXABI_H be removed? If no, mind if I add a >> config.h.cmake to LLD's "include...

Hi, Now lld writes relocations to the ".rela" sections only. Mips requires to use the "rel" format. So we need to be able to select format and names of relocation section, names of symbols like __rela_iplt_* / __rel_iplt_*, dynamic table tag DT_RELA / DT_REL. My current idea: - Add two virtual functions DefaultLayout::createDynamicRelocationTable() and

+ Nick On 2/19/2015 9:00 AM, Shankar Easwaran wrote: > On 2/19/2015 3:58 AM, Denis Protivensky wrote: >> Joerg: >>> I propose to add the ability to ignore undefined symbols during initial >>> resolution, and then postprocess only those undefines for the second >>> time >>> after the pass manager execution. >> Do you want to do that before or