From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Clifton To: ian@cygnus.com Cc: bfd@cygnus.com Subject: Re: Linker script documentation Date: Tue, 21 Apr 1998 15:25:00 -0000 Message-id: <199804212224.PAA30193@elmo.cygnus.com> X-SW-Source: 1998/msg00046.html Hi Ian, : Date: Mon, 13 Apr 1998 17:05:57 -0400 : From: Ian Lance Taylor : : Tonight's binutils snapshot will include a rewrite of the linker : script documentation in ld/ld.texinfo. I rewrote it in an attempt to : make it comprehensible. I would appreciate feedback from people who : actually use linker scripts. I have read through your new document and I have a few questions to ask/points to raise: In the 'Simple Linker Script Example' it says: The remaining lines define the `.data' and `.bss' sections in the output file. The `.data' output section will be at address `0x8000000'. When the `.bss' output section is defined, the value of the location counter will be `0x8000000' plus the size of the `.data' output section. The effect is that the `.bss' output section will follow immediately after the `.data' output section in memory. What about alignment ? Will the .bss section be automatically aligned to the next word boundary ? (I asssume that later sections in the document will answer that is question - I have not read that far yet. But people new to linker scripts may also be wondering about this question at this point in the text). In 'PROVIDE' it says: Here is an example of using `PROVIDE' to define `etext': SECTIONS { .text : { *(.text) _etext = .; PROVIDE(etext = .); } } In this example, if the program defines `_etext', the linker will give a multiple definition error. If, on the other hand, the program defines `etext', the linker will silently use the definition in the program. If the program references `etext' but does not define it, the linker will use the definition in the linker script. I think this example is slightly confusing, since it is not immediately obvious that 'etext' and '_etext' are seperate symbols. How about this version instead: Here is an example of using `PROVIDE' to define `etext': SECTIONS { .text : { *(.text) _text_end = .; PROVIDE(etext = .); } } In this example, if the program defines `_text_end', the linker will give a multiple definition error. If, on the other hand, the program defines `etext', the linker will silently use the definition in the program. If the program references `etext' but does not define it, the linker will use the definition in the linker script. {My eyes are starting to cross, so I will leave off reading about overlays and other fun thinhs until tomorrow. In the meantime I also have a small patch to propose which fixes a spelling mistake, and rewords a paragraph to make it clearer (IMHO).} Nick Index: ld.texinfo =================================================================== RCS file: /cvs/cvsfiles/devo/ld/ld.texinfo,v retrieving revision 1.141 diff -p -r1.141 ld.texinfo *** ld.texinfo 1998/04/14 19:55:13 1.141 --- ld.texinfo 1998/04/21 22:23:07 *************** of debugging information. *** 1338,1344 **** Every loadable or allocatable output section has two addresses. The first is the @dfn{VMA}, or virtual memory address. This is the address ! the sectin will have when the output file is run. The second is the @dfn{LMA}, or load memory address. This is the address at which the section will be loaded. In most cases the two addresses will be the same. An example of when they might be different is when a data section --- 1338,1344 ---- Every loadable or allocatable output section has two addresses. The first is the @dfn{VMA}, or virtual memory address. This is the address ! the section will have when the output file is run. The second is the @dfn{LMA}, or load memory address. This is the address at which the section will be loaded. In most cases the two addresses will be the same. An example of when they might be different is when a data section *************** You write the @samp{SECTIONS} command as *** 1417,1427 **** followed by a series of symbol assignments and output section descriptions enclosed in curly braces. ! The first line in the above example sets the special symbol @samp{.}, ! which is the location counter. If you do not specify the address of an ! output section in some other way (other ways are described later), the ! address is set from the current value of the location counter. The ! location counter is then incremented by the size of the output section. The second line defines an output section, @samp{.text}. The colon is required syntax which may be ignored for now. Within the curly braces --- 1417,1429 ---- followed by a series of symbol assignments and output section descriptions enclosed in curly braces. ! The first line inside the curly braces of the above example sets the ! address of the special symbol @samp{.}, which is the location counter. ! If you do not specify the address of an output section in some other way ! (other ways are described later), the address is set from the current ! value of the location counter. The location counter is then incremented ! by the size of the output section. By default the location counter ! starts at 0. The second line defines an output section, @samp{.text}. The colon is required syntax which may be ignored for now. Within the curly braces