On Wed, Jan 2, 2013 at 12:04 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:> You might want to look at the ELFLayout changes to see what functionality is > missing from that. > > The ELFLayoutOptions has a hook into reading the Linker script which needs > to be implemented.So, looking into it a bit, I think that ELFLayoutOptions is not the right place to parse the linker script. From what I can tell, it has to be parsed during argument processing. As Nick pointed out, most of the linker script stuff can be handled during the final writing stage, but since the script can define symbols, it has to be parsed earlier. Also, Nick's perspective was that "the linker scripts and the command line arguments should all be parsed into one set of "options" to the ELF Writer". -- Sean Silva
On Jan 6, 2013, at 2:05 PM, Sean Silva wrote:> but since the script can define symbols, it has to be parsed earlier.It is more than just defining symbols. There are many other directives that have command line option equivalents that are used to setup linking. You can pull symbols with EXTERN, add other files to link with INPUT, add groups of archives to be searched with GROUP, name the output file with OUTPUT, add new library path directories with SEARCH_DIR, etc… Also keep in mind that that linker scripts are usually "inlined" with other command line options. For example: ld foo.o --defsym=x=12 -Lbar -T beagle-ram.ld -lbaz bar.o As you said, it makes sense to parse it during command line argument parsing. -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software
Hi Sean, The hook to add symbols into the Reader is through Writer->addFiles function. I think still the linker script should be parsed by Writer. Also the linker script functionality is only needed by ELF and not anything else. It should be contained only within ELF. Thanks Shankar Easwaran On 1/6/2013 2:05 PM, Sean Silva wrote:> On Wed, Jan 2, 2013 at 12:04 PM, Shankar Easwaran > <shankare at codeaurora.org> wrote: >> You might want to look at the ELFLayout changes to see what functionality is >> missing from that. >> >> The ELFLayoutOptions has a hook into reading the Linker script which needs >> to be implemented. > So, looking into it a bit, I think that ELFLayoutOptions is not the > right place to parse the linker script. From what I can tell, it has > to be parsed during argument processing. As Nick pointed out, most of > the linker script stuff can be handled during the final writing stage, > but since the script can define symbols, it has to be parsed earlier. > Also, Nick's perspective was that "the linker scripts and the command > line arguments should all be parsed into one set of "options" to the > ELF Writer". > > -- Sean Silva > >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
On 1/6/2013 6:30 PM, Meador Inge wrote:> On Jan 6, 2013, at 2:05 PM, Sean Silva wrote: > >> but since the script can define symbols, it has to be parsed earlier. > It is more than just defining symbols. There are many other directives that > have command line option equivalents that are used to setup linking. You can pull symbols > with EXTERN, add other files to link with INPUT, add groups of archives to be searched > with GROUP, name the output file with OUTPUT, add new library path directories > with SEARCH_DIR, etc… > > Also keep in mind that that linker scripts are usually "inlined" with other command line > options. For example: > > ld foo.o --defsym=x=12 -Lbar -T beagle-ram.ld -lbaz bar.oThis is different. There are things in the command line which would a) add symbols into the output This is generic functionality which is needed by all the platforms. The symbols could be parsed and handed over to ELF Writer to add symbols, because types of symbols on what to add should be owned by the target specific format. b) specify segment address by using (-Ttext=<n>) This functionality is only needed by ELF and should be contained in WriterELF. Overall, I think that the functionality should be accessed only by WriterELF and contained within. Nick, Michael : What do you think ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
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 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 don't have an opinion on where it is needed, but I've found linker scripts to be useful in other contexts. Here's a simple one I wrote that has no relation to ELF: OUTPUT_FORMAT(binary) OUTPUT(flash.bin) SECTIONS { .text : { . = 0x2000; LONG(0xAABBCCDD); LONG(Init); LONG(Store); LONG(Erase); LONG(Write); *(.text) *(.rodata) } } (The documentation seemed to imply that I could write .text 0x2000 : AT(0), but that never worked for me, so I just stripped off 0x2000 bytes of 0 at the beginning.) Maybe there's a way to do that without linker scripts, but this was very easy. All of this is to say if it's not a lot of extra work, linker scripts should be supported outside of ELF. -- Stephen Checkoway