similar to: [LLVMdev] Need to create symbols only once

On Dec 7, 2012, at 11:51 AM, Shankar Easwaran wrote: > 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

Thanks for the reply Nick. I will use the Writer::addFiles functionality. Do you want to move the SimpleFile class to lld/Core ? It might be useful for other types of object files too(like for ELF here). How does typeFirstInSection/typeLastinSection know that the addresses that need to be used for those symbols are the symbol values for the section start / section end ? I didnt see

Hi Nick, On 12/7/2012 4:59 PM, Nick Kledzik wrote: > > We have a similar requirement in darwin's ld64 linker, but even more general. Any binary can do the following to introspect itself: > > struct stuff { int a; int b; }; > > extern struct stuff* stuff_start __asm("section$start$__DATA$__my"); > extern struct stuff* stuff_end

Hi, Right now, linker added symbols specified by the -u option do not endup in the output YAML file. This is because the target specific Writers dont get called, which creates the undefined atoms. I am in the process of adding more options and I would like the atoms created internally by the options available in the output YAML file. The options that I am trying to consider for the linker

Hi Nick, The problem is when the -emit-yaml option is used, the writer is set to the YAML writer. The YAML writer doesnot 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

Shankar, The LinkingContext has a addImplictFiles() method that is supposed to call the Writer and give it a chance to add any implicit files. Is the problem that the -u atoms are not attached to that implicit file? Or that the implicit file is not getting added? Or that this got lost in the transition from InputFiles to InputGraph? -Nick On Aug 28, 2013, at 2:44 PM, Shankar Easwaran

Hi, I am writing a function that clears the BSS section on an Cortex-M4 embedded system. The LLVM (version 3.7.0rc3) code I had wrote is : ;------------ target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64" target triple = "thumbv7em-none--eabi" @__bss_start = external global i32 @__bss_end = external global i32 define void @clearBSS () nounwind { entry:

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

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

Since upgrading to cygwin 1.7.x, I'm unable to complete rsync jobs to a Debian machine (running stable). cygwin rsync is 3.0.6; Debian is 3.0.3. The transfer goes for a while and then just gets stuck halfway through an arbitrary file. If I cancel and restart, same thing (but gets a little further). If I manually copy the file in question, it will usually go a bit longer and then get stuck

+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

Sid, It's a real problem when section GC is active. It's not very common, but, typically, global constructors and destructors are the primary instances that may be incorrectly discarded. The statement KEEP in GNU linker scripts specifies which sections should be kept in the final output even if GC judges that it could be discarded. Perhaps, at this moment, it would suffice to

On Aug 28, 2013, at 3:14 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > The problem is when the -emit-yaml option is used, the writer is set to the YAML writer. Ah! > > 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

From: Sylvain Gault <sylvain.gault at gmail.com> These patches basically remove unused linker scripts and port a change that was made to an unused script. Those are to be applied on top of the gcc 5 bug fixes as they would conflict otherwise. Sylvain Gault (4): diag/mbr: fix dependency to linker script Remove unused linker scripts core: Make symbols defined in linker script HIDDEN

Hi Nick, On 8/28/2013 6:37 PM, Nick Kledzik wrote > $cat 1.c > int _start() { return 0; } > $gcc -c 1.c > $ld -u myundef 1.o > ==> Does not throw any error, the resolver was hinted that myundef was a undefined weak symbol. > Wow. Reading the gnu ld man page, that is not obvious. How can you make a non-weak undefined on the command line? That is, how can you force and error

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

On Aug 28, 2013, at 4:24 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > >> Also for the case of -u, the Driver can make generic UndefinedAtoms. > ELF would want to treat the undefined symbols as a weak undefined symbols. So the driver cant create undefined atoms. > > Below is an example :- > > $cat 1.c > int _start() { return 0; }

On 06/30/2012 07:16 PM, Michael Spencer wrote: > 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

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