On Mon, Jan 7, 2013 at 9:44 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:> Also the linker script functionality is only needed by ELF and not anything > else. It should be contained only within ELF.I agree with your point about encapsulation and separation of concerns. However, I believe that GNU ld will accept and use linker scripts even for the non-ELF formats it supports (not that we intend to emulate that behavior necessarily), so they aren't ELF-specific per se. Thus I feel that the right categorization might be "GNU ld"-only, and hence it would naturally be just a component of the GNU ld frontend, where it would be isolated from the rest of LLD. -- Sean Silva
> On Mon, Jan 7, 2013 at 9:44 AM, Shankar Easwaran > <shankare at codeaurora.org> wrote: >> Also the linker script functionality is only needed by ELF and not >> anything >> else. It should be contained only within ELF. > > I agree with your point about encapsulation and separation of > concerns. However, I believe that GNU ld will accept and use linker > scripts even for the non-ELF formats it supports (not that we intend > to emulate that behavior necessarily), so they aren't ELF-specific per > se. Thus I feel that the right categorization might be "GNU ld"-only, > and hence it would naturally be just a component of the GNU ld > frontend, where it would be isolated from the rest of LLD. >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 ? 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 ? Maybe the first version could be just ELF centric. Thanks Shankar Easwaran
I agree that processing of linker scripts is a "flavor" issue. We have an in-house linker that processes them and has a different command line than GNU ld, so we'll want to process them in that "flavor" as we'll. Sent from my iPad On Jan 8, 2013, at 11:44 PM, Sean Silva <silvas at purdue.edu> wrote:> On Mon, Jan 7, 2013 at 9:44 AM, Shankar Easwaran > <shankare at codeaurora.org> wrote: >> Also the linker script functionality is only needed by ELF and not anything >> else. It should be contained only within ELF. > > I agree with your point about encapsulation and separation of > concerns. However, I believe that GNU ld will accept and use linker > scripts even for the non-ELF formats it supports (not that we intend > to emulate that behavior necessarily), so they aren't ELF-specific per > se. Thus I feel that the right categorization might be "GNU ld"-only, > and hence it would naturally be just a component of the GNU ld > frontend, where it would be isolated from the rest of LLD. > > -- Sean Silva
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 Wed, Jan 9, 2013 at 1:54 PM, Alex Rosenberg <alexr at leftfield.org> wrote:> I agree that processing of linker scripts is a "flavor" issue. We have an in-house linker that processes them and has a different command line than GNU ld, so we'll want to process them in that "flavor" as we'll.Is it the same language that GNU ld accepts? -- Sean Silva