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 morenatural 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
On Jan 2, 2013, at 5:51 PM, Sean Silva wrote:>> 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.Yes, the linker scripts and the command line arguments should all be parsed into one set of "options" to the ELF Writer. My point was that most of linker script options don't need to be handled until the last stage of linking when the Writer is handed the atom graph to turn into the output file. The one exception to that is any symbols that need to be defined because of linker scripts (or --defsym). -Nick
On Wed, Jan 2, 2013 at 11:30 PM, Nick Kledzik <kledzik at apple.com> wrote:> My point was that most of linker script options don't need to be handled > until the last stage of linking when the Writer is handed the atom graph > to turn into the output file. The one exception to that is any symbols > that need to be defined because of linker scripts (or --defsym).Ah, I see now. That's a good observation; I hadn't thought about at what phase each part of the script would need to be handled, only the interface between the language processor and "everything else". -- Sean Silva