search for: writeoptionself

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

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

...iters (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 > concerne...