When a BFD is opened for reading, the section structures are created and attached to the BFD.
Each section has a name which describes the section in the
outside world—for example, a.out would contain at least
three sections, called .text, .data and .bss.
Names need not be unique; for example a COFF file may have several
sections named .data.
Sometimes a BFD will contain more than the “natural” number of
sections. A back end may attach other sections containing
constructor data, or an application may add a section (using
bfd_make_section) to the sections attached to an already open
BFD. For example, the linker creates an extra section
COMMON for each input file's BFD to hold information about
common storage.
The raw data is not necessarily read in when
the section descriptor is created. Some targets may leave the
data in place until a bfd_get_section_contents call is
made. Other back ends may read in all the data at once. For
example, an S-record file has to be read once to determine the
size of the data. An IEEE-695 file doesn't contain raw data in
sections, but data and relocation expressions intermixed, so
the data area has to be parsed to get out the data and
relocations.