Next: typedef asection, Previous: Section Input, Up: Sections

#### 2.6.2 Section output

To write a new object style BFD, the various sections to be written have to be created. They are attached to the BFD in the same way as input sections; data is written to the sections using `bfd_set_section_contents`.

Any program that creates or combines sections (e.g., the assembler and linker) must use the `asection` fields `output_section` and `output_offset` to indicate the file sections to which each section must be written. (If the section is being created from scratch, `output_section` should probably point to the section itself and `output_offset` should probably be zero.)

The data to be written comes from input sections attached (via `output_section` pointers) to the output sections. The output section structure can be considered a filter for the input section: the output section determines the vma of the output data and the name, but the input section determines the offset into the output section of the data to be written.

E.g., to create a section "O", starting at 0x100, 0x123 long, containing two subsections, "A" at offset 0x0 (i.e., at vma 0x100) and "B" at offset 0x20 (i.e., at vma 0x120) the `asection` structures would look like:

            section name          "A"
              output_offset   0x00
              size            0x20
              output_section ----------->  section name    "O"
                                      |    vma             0x100
            section name          "B" |    size            0x123
              output_offset   0x20    |
              size            0x103   |
              output_section  --------|

#### 2.6.3 Link orders

The data within a section is stored in a link_order. These are much like the fixups in `gas`. The link_order abstraction allows a section to grow and shrink within itself.

A link_order knows how big it is, and which is the next link_order and where the raw data for it is; it also points to a list of relocations which apply to it.

The link_order is used by the linker to perform relaxing on final code. The compiler creates code which is as big as necessary to make it work without relaxing, and the user can select whether to relax. Sometimes relaxing takes a lot of time. The linker runs around the relocations to see if any are attached to data which can be shrunk, if so it does it on a link_order by link_order basis.