On Wed, Jan 9, 2013 at 9:13 AM, <shankare at codeaurora.org> wrote:> I dont think any other format has the functionality of sections and > segments with segment and section permissions etc. > > Are you planning to mimic 1-1 lld to ld linker script functionality ?No, there's lots of arcane things that GNU ld has (like compatibility with a completely different linker script language). Pragmatically it makes sense to at least support enough to link Linux.> Do you by any chance have a proposal of how the lld linker script would > look if there is a difference b/w ld and lld linker scripts ?I don't see any reason to support anything except a strict subset of ld's language. What kind of difference are you thinking of?> Maybe the first version could be just ELF centric.The consensus in this thread seems to be that it should be in the frontend. Nick pointed out that since linker scripts can define symbols, they need to be handled before the writer; I don't see any way to avoid that. Could you elaborate on the concrete reasons why you think it should be in the ELF backend? -- Sean Silva
On Jan 9, 2013, at 12:29 PM, Sean Silva wrote:>> Maybe the first version could be just ELF centric. > > The consensus in this thread seems to be that it should be in the > frontend. Nick pointed out that since linker scripts can define > symbols, they need to be handled before the writer; I don't see any > way to avoid that. Could you elaborate on the concrete reasons why you > think it should be in the ELF backend?We need to be careful about what we mean by "frontend" and "backend" of lld. The Writer (backend?) actually gets a chance to contribute atoms along with the Reader atoms which are fed to the Resolver. So the linker script code could live in WriterELF and contribute atoms for symbols defined by a linker script. That being said, some of the functionality of linker scripts is done via command line options on other platforms, so we want to share common functionality were possible. The linker script parsing may wind up being a thin layer (in WriterELF) on top of some shared functionality. -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 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").> So the linker script code could live in WriterELF and contribute atoms > for symbols defined by a linker script. > > That being said, some of the functionality of linker scripts is done via > command line options on other platforms, so we want to share common > functionality were possible. The linker script parsing may wind up > being a thin layer (in WriterELF) on top of some shared functionality.Ok. -- Sean Silva
On 01/09/2013 07:47 PM, Nick Kledzik wrote:> So the linker script code could live in WriterELF and contribute atoms > for symbols defined by a linker script.I am still getting up to speed with the LLD architecture so maybe I am missing something, but that seems like a odd place to put it. I would think that a Writer would only be focused on serializing atoms to their respective format. Since the linker script is an input it would seem more natural to me to have some sort of linker script Reader that can contribute symbol definitions, external symbols, new libraries, library search paths, etc... (to process LD script directives like PROVIDE, EXTERN, INPUT, GROUP, SEARCH_DIR, and OUTPUT). -- Meador Inge CodeSourcery / Mentor Embedded