similar to: [LLVMdev] lld Atoms from STT_SECTION type symbols.

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

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

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 Jan 9, 2013, at 12:29 PM, Sean Silva wrote: >> Maybe the first version could be just ELF centric. > > The consensus in this thread seems to be that it should be in the > frontend. Nick pointed out that since linker scripts can define > symbols, they need to be handled before the writer; I don't see any > way to avoid that. Could you elaborate on the concrete reasons

On Jan 10, 2013, at 4:09 PM, Sean Silva wrote: > On Thu, Jan 10, 2013 at 1:55 PM, Nick Kledzik <kledzik at apple.com> wrote: >> The reality is that some content is tied to the format. That is, Writers do not >> just lay down the content of the atoms supplied and then put some file format >> wrapper around that content. Some of the content exists because of >>

On Wed, Jan 9, 2013 at 8:47 PM, Nick Kledzik <kledzik at apple.com> wrote: > We need to be careful about what we mean by "frontend" and "backend" > of lld. Yeah, that terminology was really vague. I identify "frontend" with the driver (GNU ld, link.exe, ld64, etc) and "backend" with ReaderWriter (i.e. roughly the object file formats). > The

On 1/6/2013 6:30 PM, Meador Inge wrote: > On Jan 6, 2013, at 2:05 PM, Sean Silva wrote: > >> but since the script can define symbols, it has to be parsed earlier. > It is more than just defining symbols. There are many other directives that > have command line option equivalents that are used to setup linking. You can pull symbols > with EXTERN, add other files to link with

On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: > > I think that absolute atoms will need something similar to, "contentType" added. > > SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a

On Oct 15, 2012, at 4:00 PM, Sid Manning wrote: > On 10/15/12 12:01, Nick Kledzik wrote: >> >> On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: >>> >>> I think that absolute atoms will need something similar to, "contentType" added. >>> >>> SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order

On Oct 23, 2012, at 1:01 PM, Shankar Easwaran wrote: > 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 >

On Thu, Jan 10, 2013 at 1:55 PM, Nick Kledzik <kledzik at apple.com> wrote: > The reality is that some content is tied to the format. That is, Writers do not > just lay down the content of the atoms supplied and then put some file format > wrapper around that content. Some of the content exists because of > the file format, for instance GOT and PLT entires. > > Now in the

On Jan 9, 2013, at 6:49 PM, Sean Silva wrote: >> The Writer (backend?) actually gets a chance to contribute >> atoms along with the Reader atoms which are fed to the Resolver. > > Could you elaborate on this? My understanding is that ReaderWriter is > supposed to be basically a toolkit for emitting the object files > ("mechanism"), while the different drivers use

On Oct 15, 2012, at 9:06 PM, Shankar Kalpathi Easwaran wrote: > The object file already has the information that when its STT_FILE and the symbol name is the name of the translation unit already. > > I dont think the linker has to add a absolute symbol by figuring out the translation unit. Then we are in agreement. Sid started this thread with the suggestion of adding new content

On 10/15/12 12:01, Nick Kledzik wrote: > > On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: >> >> I think that absolute atoms will need something similar to, "contentType" added. >> >> SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type

Hi Nick, The object file already has the information that when its STT_FILE and the symbol name is the name of the translation unit already. I dont think the linker has to add a absolute symbol by figuring out the translation unit. Shankar Easwaran On Mon, Oct 15, 2012 at 6:07 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Oct 15, 2012, at 4:00 PM, Sid Manning 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 function is called from ObjectFile::createELFObjectFile the > pointer to

While working on some other changes I came across a problem where ELFObjectFile::getSymbolFileOffset was returning a different value than I expected in the case where the symbol in question was a section. Looking at the code, it seems obviously wrong, but I didn't want to just commit my change without at least asking if anyone knew of a good reason for the current behavior. I know there