[LLVMdev] [lld] Linker script findings.

[Sean Silva]

On Wed, Jan 2, 2013 at 2:53 PM, Nick Kledzik <kledzik at apple.com> wrote:
> The SECTION and MEMORY seem doable in lld as part of the ELF
> Writer.

MEMORY and most aspects of SECTIONS are effectively syntax sugar and
the rest of LLD doesn't need to even be aware of it; the ldscript
language processor will desugar it. The same is true of many other
linker script constructs that I didn't mention. The goal of the
write-up was to describe the primitive functionality that will be
needed at the boundary between the language processor and the rest of
LLD (although admittedly some parts of the write-up still herald from
when I was intending to write about the entire language itself; sorry
for the confusion).

To be clear, I did learn the entire language in distilling this list
of primitive functionality (so there should be no (major) surprises in
that regard), but I decided that the existing documentation about the
language itself was good enough to obviate the need to distill a
reference for the entire ldscript language.

> The one tricky part will be if the linker script defines symbols
> (e.g.  __text_size), because those symbol names might be
> referenced by some object file atom. Thus they need an atom
> representation for lld's Resolver to see.  So, the ELF Writer will need
> to make a first pass at the linker script and make "proxy" atoms for
> any symbols the linker script defines.

Does it make sense for the ELF Writer to call into the linker script?
>From what I know about linker scripts, it seems like it is more
natural to treat them like commandline argument processing, which
"calls into" the ELF Writer rather than being "called from" the ELF
Writer (indeed, many linker script constructs are isomorphic to
certain commandline options). Indeed, `--defsym` can be used to create
symbols and it is probably best to share a common code path.

-- Sean Silva