GNU Info

(bfd.info)Section Output

---

Next: typedef asection Prev: Section Input Up: Sections

---

Enter node , (file) or (file)node

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  --------|

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.


automatically generated by info2www version 1.2.2.9