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

+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

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

Since Jakob had expressed some concerns regarding machine-generated files, I asked him by email about his views on this RFC. Here are the emails that we exchanged in attach. Anyone feel free to jump in via the mailing-list. TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum -------------- next

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

I've noticed that lld keeps the data section more isolated than the gold or bfd linkers. For example, readelf -l applied to the "same" executable linked with those three linkers reveals the following under "Section to Segment mapping": lld: 05 .data .got.plt .bss gold: 03 .eh_frame .init_array .fini_array .preinit_array .dynamic .got .got.plt .data .bss bfd: 05

I'd appreciate some help in figuring out how to determine which InstrItinClass an instruction belongs to. For example, an InstrItinClass is defined in Schedule.td as: def FOO : InstrItinClass; Which is then used to build an InstrItinData in ProcessorItineraries and to specify the class of a particular instruction. I'd like to find out from a given instruction which class it belongs

On 08/21/12 16:49, Jim Grosbach wrote: > > I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. > > Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :( This proposal would certainly make my life easier

Hello, I believe MCInstrDesc::getSchedClass() is what you're looking for. -Jim On Nov 28, 2011, at 5:03 PM, Evandro Menezes wrote: > I'd appreciate some help in figuring out how to determine which > InstrItinClass an instruction belongs to. > > For example, an InstrItinClass is defined in Schedule.td as: > > def FOO : InstrItinClass; > > Which is then used

Sebastian, If not a test, how about a patch in the documentation for TableGen about this new feature that you're making available? -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 06/20/12 16:02, Sebastian Pop wrote: > On Wed, Jun 20, 2012 at 3:40 PM, Villmow, Micah<Micah.Villmow at

On Aug 22, 2012, at 9:40 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: > On 08/21/12 16:49, Jim Grosbach wrote: >> >> I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. >> >> Beyond that, I don't see an alternative to an audit

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

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