2
votes

After reading enough documentation about the GNU linker, I feel confused about combining two different concepts regarding implementing custom linker file.

First concept is orphan sections-

If there is no output section with a matching name then new output sections will be created. Each new output section will have the same name as the orphan section placed within it. If there are multiple orphan sections with the same name, these will all be combined into one new output section. If new output sections are created to hold orphaned input sections, then the linker must decide where to place these new output sections in relation to existing output sections. On most modern targets, the linker attempts to place orphan sections after sections of the same attribute, such as code vs data, loadable vs non-loadable, etc. If no sections with matching attributes are found, or your target lacks this support, the orphan section is placed at the end of the file.

Second concept is about symbol assignment-

Here is an example showing the three different places that symbol assignments may be used:

floating_point = 0;
SECTIONS
{
  .text :
    {
      *(.text)
      _etext = .;
    }
  _bdata = (. + 3) & ~ 3;
  .data : { *(.data) }
}

In this example, the symbol ‘floating_point’ will be defined as zero. The symbol ‘_etext’ will be defined as the address following the last ‘.text’ input section. The symbol ‘_bdata’ will be defined as the address following the ‘.text’ output section aligned upward to a 4 byte boundary.

So, the bold explanation regarding orphan sections dictates that is possible that in the above example, the linker will place another output sections after .text output section, which means that the bold text in the symbol assignment explanation is wrong.

So, is this example can produce undesired value into the _bdata symbol if orphan section exist in it?

1

1 Answers

1
votes

Answer found on Sourceware LD documentation inside the The Location Counter chapter-

Setting symbols to the value of the location counter outside of an output section statement can result in unexpected values if the linker needs to place orphan sections.

 SECTIONS {
     start_of_text = . ;
     .text: { *(.text) }
     end_of_text = . ;

     start_of_data = . ;
     .rodata: { *(.rodata) }
     .data: { *(.data) }
     end_of_data = . ; }

This may or may not be the script author’s intention for the value of start_of_data.

So it seems that their documentation with the symbol assignment example and explanation should be edited to mention orphan sections, or removed.