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 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 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 > being a thin layer (in WriterELF) on top of some shared functionality.Ok. -- Sean Silva
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 those APIs (along with > the Atom core linking model "mechanism") to emulate their respective > linkers (the "policy").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 case of PLT entries the overall algorithm is similar to what darwin needs for "stubs". So the abstract algorithm is an a Pass and each Writer supplies additions to that Pass which generate platform/Writer specific atoms as needed. Perhaps the name "Writer" is causing confusion. In a previous incarnation we called in "Platform". But that caused confusion because does platform mean the OS or the file format? And LLVM uses "target" to mean many things too. My pragmatic approach is that any (non-driver) code that only mach-o/darwin will need should go in lib/ReaderWriter/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 WriteOptionsELF. -Nick
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 case of PLT entries the overall algorithm is similar to what > darwin needs for "stubs". So the abstract algorithm is an a Pass and > each Writer supplies additions to that Pass which generate platform/Writer > specific atoms as needed. > > Perhaps the name "Writer" is causing confusion. In a previous incarnation > we called in "Platform". But that caused confusion because does platform > mean the OS or the file format? And LLVM uses "target" to mean many > things too. > > My pragmatic approach is that any (non-driver) code that only mach-o/darwin > will need should go in lib/ReaderWriter/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 WriteOptionsELF.Interesting. As you have pointed out, currently the format and the os are conflated. Would it make sense to have Reader/Writer literally be concerned *only* with turning an atom graph into an output object file in a specific format? (each format may have format-specific atoms). Then the OS layer (+ architecture?) is implemented in a separate library that is a client of Reader/Writer. How do you expect WriterOptionsELF to scale with respect to the number of OS's and architectures supported? E.g. for each architecture, will we need to add to WriterOptionsELF? For each OS, will we need to add to it? -- Sean Silva