[LLVMdev] [lld] Linker script findings.

[Nick Kledzik]

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