/* Object file "section" support for the BFD library.   Copyright 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,   2000, 2001   Free Software Foundation, Inc.   Written by Cygnus Support.This file is part of BFD, the Binary File Descriptor library.This program is free software; you can redistribute it and/or modifyit under the terms of the GNU General Public License as published bythe Free Software Foundation; either version 2 of the License, or(at your option) any later version.This program is distributed in the hope that it will be useful,but WITHOUT ANY WARRANTY; without even the implied warranty ofMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See theGNU General Public License for more details.You should have received a copy of the GNU General Public Licensealong with this program; if not, write to the Free SoftwareFoundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  *//*SECTION	Sections	The raw data contained within a BFD is maintained through the	section abstraction.  A single BFD may have any number of	sections.  It keeps hold of them by pointing to the first;	each one points to the next in the list.	Sections are supported in BFD in <<section.c>>.@menu@* Section Input::@* Section Output::@* typedef asection::@* section prototypes::@end menuINODESection Input, Section Output, Sections, SectionsSUBSECTION	Section input	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.INODESection Output, typedef asection, Section Input, SectionsSUBSECTION	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  --------|SUBSECTION	Link orders	The data within a section is stored in a @dfn{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.*/#include "bfd.h"#include "sysdep.h"#include "libbfd.h"#include "bfdlink.h"/*DOCDDINODEtypedef asection, section prototypes, Section Output, SectionsSUBSECTION	typedef asection	Here is the section structure:CODE_FRAGMENT..{* This structure is used for a comdat section, as in PE.  A comdat.   section is associated with a particular symbol.  When the linker.   sees a comdat section, it keeps only one of the sections with a.   given name and associated with a given symbol.  *}..struct bfd_comdat_info.{.  {* The name of the symbol associated with a comdat section.  *}.  const char *name;..  {* The local symbol table index of the symbol associated with a.     comdat section.  This is only meaningful to the object file format.     specific code; it is not an index into the list returned by.     bfd_canonicalize_symtab.  *}.  long symbol;.};..typedef struct sec.{.  {* The name of the section; the name isn't a copy, the pointer is.     the same as that passed to bfd_make_section.  *}..  const char *name;..  {* A unique sequence number.  *}..  int id;..  {* Which section is it; 0..nth.  *}..  int index;..  {* The next section in the list belonging to the BFD, or NULL.  *}..  struct sec *next;..  {* The field flags contains attributes of the section. Some.     flags are read in from the object file, and some are.     synthesized from other information.  *}..  flagword flags;..#define SEC_NO_FLAGS   0x000..  {* Tells the OS to allocate space for this section when loading..     This is clear for a section containing debug information only.  *}.#define SEC_ALLOC      0x001..  {* Tells the OS to load the section from the file when loading..     This is clear for a .bss section.  *}.#define SEC_LOAD       0x002..  {* The section contains data still to be relocated, so there is.     some relocation information too.  *}.#define SEC_RELOC      0x004..#if 0   {* Obsolete ? *}.#define SEC_BALIGN     0x008.#endif..  {* A signal to the OS that the section contains read only data.  *}.#define SEC_READONLY   0x010..  {* The section contains code only.  *}.#define SEC_CODE       0x020..  {* The section contains data only.  *}.#define SEC_DATA       0x040..  {* The section will reside in ROM.  *}.#define SEC_ROM        0x080..  {* The section contains constructor information. This section.     type is used by the linker to create lists of constructors and.     destructors used by <<g++>>. When a back end sees a symbol.     which should be used in a constructor list, it creates a new.     section for the type of name (e.g., <<__CTOR_LIST__>>), attaches.     the symbol to it, and builds a relocation. To build the lists.     of constructors, all the linker has to do is catenate all the.     sections called <<__CTOR_LIST__>> and relocate the data.     contained within - exactly the operations it would peform on.     standard data.  *}.#define SEC_CONSTRUCTOR 0x100..  {* The section is a constructor, and should be placed at the.     end of the text, data, or bss section(?).  *}.#define SEC_CONSTRUCTOR_TEXT 0x1100.#define SEC_CONSTRUCTOR_DATA 0x2100.#define SEC_CONSTRUCTOR_BSS  0x3100..  {* The section has contents - a data section could be.     <<SEC_ALLOC>> | <<SEC_HAS_CONTENTS>>; a debug section could be.     <<SEC_HAS_CONTENTS>>  *}.#define SEC_HAS_CONTENTS 0x200..  {* An instruction to the linker to not output the section.     even if it has information which would normally be written.  *}.#define SEC_NEVER_LOAD 0x400..  {* The section is a COFF shared library section.  This flag is.     only for the linker.  If this type of section appears in.     the input file, the linker must copy it to the output file.     without changing the vma or size.  FIXME: Although this.     was originally intended to be general, it really is COFF.     specific (and the flag was renamed to indicate this).  It.     might be cleaner to have some more general mechanism to.     allow the back end to control what the linker does with.     sections.  *}.#define SEC_COFF_SHARED_LIBRARY 0x800..  {* The section has GOT references.  This flag is only for the.     linker, and is currently only used by the elf32-hppa back end..     It will be set if global offset table references were detected.     in this section, which indicate to the linker that the section.     contains PIC code, and must be handled specially when doing a.     static link.  *}.#define SEC_HAS_GOT_REF 0x4000..  {* The section contains common symbols (symbols may be defined.     multiple times, the value of a symbol is the amount of.     space it requires, and the largest symbol value is the one.     used).  Most targets have exactly one of these (which we.     translate to bfd_com_section_ptr), but ECOFF has two.  *}.#define SEC_IS_COMMON 0x8000..  {* The section contains only debugging information.  For.     example, this is set for ELF .debug and .stab sections..     strip tests this flag to see if a section can be.     discarded.  *}.#define SEC_DEBUGGING 0x10000..  {* The contents of this section are held in memory pointed to.     by the contents field.  This is checked by bfd_get_section_contents,.     and the data is retrieved from memory if appropriate.  *}.#define SEC_IN_MEMORY 0x20000..  {* The contents of this section are to be excluded by the.     linker for executable and shared objects unless those.     objects are to be further relocated.  *}.#define SEC_EXCLUDE 0x40000..  {* The contents of this section are to be sorted by the.     based on the address specified in the associated symbol.     table.  *}.#define SEC_SORT_ENTRIES 0x80000..  {* When linking, duplicate sections of the same name should be.     discarded, rather than being combined into a single section as.     is usually done.  This is similar to how common symbols are.     handled.  See SEC_LINK_DUPLICATES below.  *}.#define SEC_LINK_ONCE 0x100000..  {* If SEC_LINK_ONCE is set, this bitfield describes how the linker.     should handle duplicate sections.  *}.#define SEC_LINK_DUPLICATES 0x600000..  {* This value for SEC_LINK_DUPLICATES means that duplicate.     sections with the same name should simply be discarded.  *}.#define SEC_LINK_DUPLICATES_DISCARD 0x0..  {* This value for SEC_LINK_DUPLICATES means that the linker.     should warn if there are any duplicate sections, although.     it should still only link one copy.  *}.#define SEC_LINK_DUPLICATES_ONE_ONLY 0x200000..  {* This value for SEC_LINK_DUPLICATES means that the linker.     should warn if any duplicate sections are a different size.  *}.#define SEC_LINK_DUPLICATES_SAME_SIZE 0x400000..  {* This value for SEC_LINK_DUPLICATES means that the linker.     should warn if any duplicate sections contain different.     contents.  *}.#define SEC_LINK_DUPLICATES_SAME_CONTENTS 0x600000..  {* This section was created by the linker as part of dynamic.     relocation or other arcane processing.  It is skipped when.     going through the first-pass output, trusting that someone.     else up the line will take care of it later.  *}.#define SEC_LINKER_CREATED 0x800000..  {* This section should not be subject to garbage collection.  *}.#define SEC_KEEP 0x1000000..  {* This section contains "short" data, and should be placed.     "near" the GP.  *}.#define SEC_SMALL_DATA 0x2000000..  {* This section contains data which may be shared with other.     executables or shared objects.  *}.#define SEC_SHARED 0x4000000..  {* When a section with this flag is being linked, then if the size of.     the input section is less than a page, it should not cross a page.     boundary.  If the size of the input section is one page or more, it.     should be aligned on a page boundary.  *}.#define SEC_BLOCK 0x8000000..  {* Conditionally link this section; do not link if there are no.     references found to any symbol in the section.  *}.#define SEC_CLINK 0x10000000..  {*  End of section flags.  *}..  {* Some internal packed boolean fields.  *}..  {* See the vma field.  *}.  unsigned int user_set_vma : 1;..  {* Whether relocations have been processed.  *}.  unsigned int reloc_done : 1;..  {* A mark flag used by some of the linker backends.  *}.  unsigned int linker_mark : 1;..  {* Another mark flag used by some of the linker backends.  Set for.     output sections that have a input section.  *}.  unsigned int linker_has_input : 1;..  {* A mark flag used by some linker backends for garbage collection.  *}.  unsigned int gc_mark : 1;..  {* Used by the ELF code to mark sections which have been allocated to segments.  *}.  unsigned int segment_mark : 1;..  {* End of internal packed boolean fields.  *}..  {*  The virtual memory address of the section - where it will be.      at run time.  The symbols are relocated against this.  The.      user_set_vma flag is maintained by bfd; if it's not set, the.      backend can assign addresses (for example, in <<a.out>>, where.      the default address for <<.data>> is dependent on the specific.      target and various flags).  *}..  bfd_vma vma;..  {*  The load address of the section - where it would be in a.      rom image; really only used for writing section header.      information. *}..  bfd_vma lma;..  {* The size of the section in octets, as it will be output..     Contains a value even if the section has no contents (e.g., the.     size of <<.bss>>).  This will be filled in after relocation.  *}..  bfd_size_type _cooked_size;..  {* The original size on disk of the section, in octets.  Normally this.     value is the same as the size, but if some relaxing has.     been done, then this value will be bigger.  *}..  bfd_size_type _raw_size;..  {* If this section is going to be output, then this value is the.     offset in *bytes* into the output section of the first byte in the.     input section (byte ==> smallest addressable unit on the.     target).  In most cases, if this was going to start at the.     100th octet (8-bit quantity) in the output section, this value.     would be 100.  However, if the target byte size is 16 bits.     (bfd_octets_per_byte is "2"), this value would be 50.  *}..  bfd_vma output_offset;..  {* The output section through which to map on output.  *}..  struct sec *output_section;..  {* The alignment requirement of the section, as an exponent of 2 -.     e.g., 3 aligns to 2^3 (or 8).  *}..  unsigned int alignment_power;