search for: writerelf

...it should be in the ELF backend? We need to be careful about what we mean by "frontend" and "backend" of lld. The Writer (backend?) actually gets a chance to contribute atoms along with the Reader atoms which are fed to the Resolver. So the linker script code could live in WriterELF and contribute atoms for symbols defined by a linker script. That being said, some of the functionality of linker scripts is done via command line options on other platforms, so we want to share common functionality were possible. The linker script parsing may wind up being a thin layer (in Wri...

On Wed, Jan 9, 2013 at 9:13 AM, <shankare at codeaurora.org> wrote: > I dont think any other format has the functionality of sections and > segments with segment and section permissions etc. > > Are you planning to mimic 1-1 lld to ld linker script functionality ? No, there's lots of arcane things that GNU ld has (like compatibility with a completely different linker script

...orms. The symbols could be parsed and handed over to ELF Writer to add symbols, because types of symbols on what to add should be owned by the target specific format. b) specify segment address by using (-Ttext=<n>) This functionality is only needed by ELF and should be contained in WriterELF. Overall, I think that the functionality should be accessed only by WriterELF and contained within. Nick, Michael : What do you think ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

...osed to be basically a toolkit for emitting the object files ("mechanism"), while the different drivers use those APIs (along with the Atom core linking model "mechanism") to emulate their respective linkers (the "policy"). > So the linker script code could live in WriterELF and contribute atoms > for symbols defined by a linker script. > > That being said, some of the functionality of linker scripts is done via > command line options on other platforms, so we want to share common > functionality were possible. The linker script parsing may wind up >...

...imilarly, and code that > is only needed by some platform that uses ELF should go in lib/ReaderWriter/ELF. Any common processing of atoms should be done > in a Pass which has hooks allowing specialization by Writers (aka platforms). > > Another way to look at the current design is that WriterELF needs to support > every processor/platform ELF output. Exactly what it does is controlled > (configured) by WriterOptionsELF. The driver's job is to produce the right > WriteOptionsELF settings. For library based linking (no command line) > you just just code to instantiate an...

...e that >> is only needed by some platform that uses ELF should go in lib/ReaderWriter/ELF. Any common processing of atoms should be done >> in a Pass which has hooks allowing specialization by Writers (aka platforms). >> >> Another way to look at the current design is that WriterELF needs to support >> every processor/platform ELF output. Exactly what it does is controlled >> (configured) by WriterOptionsELF. The driver's job is to produce the right >> WriteOptionsELF settings. For library based linking (no command line) >> you just just code to...

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 INPUT, add groups of archives to be searched with GROUP, name the

...erWriter/MachO. Similarly, and code that is only needed by some platform that uses ELF should go in lib/ReaderWriter/ELF. Any common processing of atoms should be done in a Pass which has hooks allowing specialization by Writers (aka platforms). Another way to look at the current design is that WriterELF needs to support every processor/platform ELF output. Exactly what it does is controlled (configured) by WriterOptionsELF. The driver's job is to produce the right WriteOptionsELF settings. For library based linking (no command line) you just just code to instantiate an appropriate WriteOpt...

...pproach, you could have your WriteELF::addFiles() return a regular object file that has atoms named __bss_start and __bss_end, but they are marked mergeAsWeak so that any user defined atoms will override them. The case I have is a bit different now. I added symbols __bss_start/__bss_end/_end using WriterELF::addFiles(). The symbols get overridden appropriately but the value of the symbols are known only after the sections have been merged and the virtual addresses assigned to those symbols. So when I am trying to write these atoms to the output file, I want to set the value of these symbols to th...

On Wed, Jan 2, 2013 at 12:04 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > You might want to look at the ELFLayout changes to see what functionality is > missing from that. > > The ELFLayoutOptions has a hook into reading the Linker script which needs > to be implemented. So, looking into it a bit, I think that ELFLayoutOptions is not the right place to parse the

+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 > STT_SECTION but I don't think that is safe. This section would never > make it into t...

...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 > STT_SECTION but I don't think that is safe. This section would never > make it into...

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

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