[LLVMdev] [lld] Linker script findings.

Sean Silva silvas at purdue.edu
Thu Jan 10 16:09:34 PST 2013


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



More information about the llvm-dev mailing list