search for: readerelf

Hi Nick, We have few symbols like __bss_start, __bss_end, which are Undefined symbols in the code. I want a way in the Reader to create specific atoms before the linker bootstraps. I didnt find a way to do that with the existing interfaces. The way it needs to work is as below :- 1) ReaderELF creates Absolute symbols (for __bss_start, __bss_end etc) 2) ReaderELF reads each file and adds Atoms to the list 3) If the atoms the linker defined were Global, the atoms that the Reader created should get overridden with the linker created ones. This may also be needed to pul in specific symbol...

..., which are Undefined symbols in the code. >> >> I want a way in the Reader to create specific atoms before the linker bootstraps. >> >> I didnt find a way to do that with the existing interfaces. >> >> The way it needs to work is as below :- >> >> 1) ReaderELF creates Absolute symbols (for __bss_start, __bss_end etc) >> 2) ReaderELF reads each file and adds Atoms to the list >> 3) If the atoms the linker defined were Global, the atoms that the Reader created should get overridden with the linker created ones. >> >> This may also b...

...like __bss_start, __bss_end, which are Undefined symbols in the code. > > I want a way in the Reader to create specific atoms before the linker bootstraps. > > I didnt find a way to do that with the existing interfaces. > > The way it needs to work is as below :- > > 1) ReaderELF creates Absolute symbols (for __bss_start, __bss_end etc) > 2) ReaderELF reads each file and adds Atoms to the list > 3) If the atoms the linker defined were Global, the atoms that the Reader created should get overridden with the linker created ones. > > This may also be needed to pul...

...curring with ELF.h in lld? If so this sounds like your > compiling llvm and lld with different standard libraries and because > -O0 doesn't inline, the linkonce linkage is picking the wrong one. Yes, this is happening with ELF.h in lld; so that may be what is happening. I'm testing ReaderELF.h with a version of lld-core that reads objects rather than YAML. What is the fix, build everything with std=c++0x? Thanks,

...ition to archives, you might have yaml or native .o files that you want to support linking in. So I'm sure this issue will be refactored a few times until we are happy. At this point, I would just have a static method in ReaderArchive the says whether the file is an archive or not. Then have ReaderELF call that method and if it returns true, call through to a ReaderArchive (passing the ReaderELF object as an option in the ReaderOptionsArchive). Also, there is an identify_magic() function in llvm/Support that may help. > b) InputFiles is a vector of Files, FileArchive doesnot derive from...

Hi Nick, Here is my understanding, 1) lld-core creates a ReaderOptionsArchive class with the (Reader, CommandLine options flag) 2) lld-core creates an object of type ReaderArchive(ReaderOptions), that users would subclass (off ArchiveLibraryFile) a) GNUArchiveLibrary b) BSDArchiveLibrary b) MachOArchiveLibrary c) COFFArchiveLibrary 3) ReaderArchive has two functions

+llvmdev On 10/01/12 21:06, Sid Manning wrote: > > I committed a patch to update the ReaderELF.cpp that, in light of some > recent changes in the writer, may need another update. WriterELF is > looking for atoms of type, typeFirstInSection (STT_SECTION) but the > reader isn't classifying those yet. > > I know there has been some discussion about discarding symbols of type...

...p the .init{.*,_array}, .fini{.*,_array} and preinit_array sections. -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 10/01/12 21:06, Sid Manning wrote: > > I committed a patch to update the ReaderELF.cpp that, in light of some > recent changes in the writer, may need another update. WriterELF is > looking for atoms of type, typeFirstInSection (STT_SECTION) but the > reader isn't classifying those yet. > > I know there has been some discussion about discarding symbols of type...

On Oct 19, 2012, at 3:41 PM, Shankar Easwaran wrote: > Hi, > > I have started to work on support for Reading archive libraries in lld and thought of using the llvm/lib/ArchiveReader for this. > > The ArchiveReader doesnot fully support GNU archive libraries (thin archives), do you think we should continue using llvm/lib/ArchiveReader ? > > I was chatting with Michael and

On Sat, Jun 30, 2012 at 7:58 AM, Sid Manning <sidneym at codeaurora.org> wrote: > > I've been debugging a segfault issue with the elfreader and I would like to > point out something that I have noticed. > > ELF.h declares an inline function, getElfArchType (MemoryBuffer *Object). >  When this function is called from ObjectFile::createELFObjectFile the > pointer to

I've been debugging a segfault issue with the elfreader and I would like to point out something that I have noticed. ELF.h declares an inline function, getElfArchType (MemoryBuffer *Object). When this function is called from ObjectFile::createELFObjectFile the pointer to Object was getting corrupted. The only thing that distinguished this pointer was that it was declared as a