154 lines
		
	
	
	
		
			8 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
			
		
		
	
	
			154 lines
		
	
	
	
		
			8 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
<html lang="en">
 | 
						|
<head>
 | 
						|
<title>Secs Background - Using as</title>
 | 
						|
<meta http-equiv="Content-Type" content="text/html">
 | 
						|
<meta name="description" content="Using as">
 | 
						|
<meta name="generator" content="makeinfo 4.7">
 | 
						|
<link title="Top" rel="start" href="index.html#Top">
 | 
						|
<link rel="up" href="Sections.html#Sections" title="Sections">
 | 
						|
<link rel="next" href="Ld-Sections.html#Ld-Sections" title="Ld Sections">
 | 
						|
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
 | 
						|
<!--
 | 
						|
This file documents the GNU Assembler "as".
 | 
						|
 | 
						|
Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001, 2002,
 | 
						|
2006, 2007 Free Software Foundation, Inc.
 | 
						|
 | 
						|
Permission is granted to copy, distribute and/or modify this document
 | 
						|
under the terms of the GNU Free Documentation License, Version 1.1
 | 
						|
or any later version published by the Free Software Foundation;
 | 
						|
with no Invariant Sections, with no Front-Cover Texts, and with no
 | 
						|
Back-Cover Texts.  A copy of the license is included in the
 | 
						|
section entitled ``GNU Free Documentation License''.
 | 
						|
 | 
						|
man end-->
 | 
						|
<meta http-equiv="Content-Style-Type" content="text/css">
 | 
						|
<style type="text/css"><!--
 | 
						|
  pre.display { font-family:inherit }
 | 
						|
  pre.format  { font-family:inherit }
 | 
						|
  pre.smalldisplay { font-family:inherit; font-size:smaller }
 | 
						|
  pre.smallformat  { font-family:inherit; font-size:smaller }
 | 
						|
  pre.smallexample { font-size:smaller }
 | 
						|
  pre.smalllisp    { font-size:smaller }
 | 
						|
  span.sc { font-variant:small-caps }
 | 
						|
  span.roman { font-family: serif; font-weight: normal; } 
 | 
						|
--></style>
 | 
						|
</head>
 | 
						|
<body>
 | 
						|
<div class="node">
 | 
						|
<p>
 | 
						|
<a name="Secs-Background"></a>Next: <a rel="next" accesskey="n" href="Ld-Sections.html#Ld-Sections">Ld Sections</a>,
 | 
						|
Up: <a rel="up" accesskey="u" href="Sections.html#Sections">Sections</a>
 | 
						|
<hr><br>
 | 
						|
</div>
 | 
						|
 | 
						|
<h3 class="section">4.1 Background</h3>
 | 
						|
 | 
						|
<p>Roughly, a section is a range of addresses, with no gaps; all data
 | 
						|
“in” those addresses is treated the same for some particular purpose. 
 | 
						|
For example there may be a “read only” section.
 | 
						|
 | 
						|
   <p><a name="index-linker_002c-and-assembler-187"></a><a name="index-assembler_002c-and-linker-188"></a>The linker <code>ld</code> reads many object files (partial programs) and
 | 
						|
combines their contents to form a runnable program.  When <span class="command">as</span>
 | 
						|
emits an object file, the partial program is assumed to start at address 0. 
 | 
						|
<code>ld</code> assigns the final addresses for the partial program, so that
 | 
						|
different partial programs do not overlap.  This is actually an
 | 
						|
oversimplification, but it suffices to explain how <span class="command">as</span> uses
 | 
						|
sections.
 | 
						|
 | 
						|
   <p><code>ld</code> moves blocks of bytes of your program to their run-time
 | 
						|
addresses.  These blocks slide to their run-time addresses as rigid
 | 
						|
units; their length does not change and neither does the order of bytes
 | 
						|
within them.  Such a rigid unit is called a <em>section</em>.  Assigning
 | 
						|
run-time addresses to sections is called <dfn>relocation</dfn>.  It includes
 | 
						|
the task of adjusting mentions of object-file addresses so they refer to
 | 
						|
the proper run-time addresses. 
 | 
						|
For the H8/300, and for the Renesas / SuperH SH,
 | 
						|
<span class="command">as</span> pads sections if needed to
 | 
						|
ensure they end on a word (sixteen bit) boundary.
 | 
						|
 | 
						|
   <p><a name="index-standard-assembler-sections-189"></a>An object file written by <span class="command">as</span> has at least three sections, any
 | 
						|
of which may be empty.  These are named <dfn>text</dfn>, <dfn>data</dfn> and
 | 
						|
<dfn>bss</dfn> sections.
 | 
						|
 | 
						|
   <p>When it generates COFF or ELF output,
 | 
						|
<span class="command">as</span> can also generate whatever other named sections you specify
 | 
						|
using the <span class="samp">.section</span> directive (see <a href="Section.html#Section"><code>.section</code></a>). 
 | 
						|
If you do not use any directives that place output in the <span class="samp">.text</span>
 | 
						|
or <span class="samp">.data</span> sections, these sections still exist, but are empty.
 | 
						|
 | 
						|
   <p>When <span class="command">as</span> generates SOM or ELF output for the HPPA,
 | 
						|
<span class="command">as</span> can also generate whatever other named sections you
 | 
						|
specify using the <span class="samp">.space</span> and <span class="samp">.subspace</span> directives.  See
 | 
						|
<cite>HP9000 Series 800 Assembly Language Reference Manual</cite>
 | 
						|
(HP 92432-90001) for details on the <span class="samp">.space</span> and <span class="samp">.subspace</span>
 | 
						|
assembler directives.
 | 
						|
 | 
						|
   <p>Additionally, <span class="command">as</span> uses different names for the standard
 | 
						|
text, data, and bss sections when generating SOM output.  Program text
 | 
						|
is placed into the <span class="samp">$CODE$</span> section, data into <span class="samp">$DATA$</span>, and
 | 
						|
BSS into <span class="samp">$BSS$</span>.
 | 
						|
 | 
						|
   <p>Within the object file, the text section starts at address <code>0</code>, the
 | 
						|
data section follows, and the bss section follows the data section.
 | 
						|
 | 
						|
   <p>When generating either SOM or ELF output files on the HPPA, the text
 | 
						|
section starts at address <code>0</code>, the data section at address
 | 
						|
<code>0x4000000</code>, and the bss section follows the data section.
 | 
						|
 | 
						|
   <p>To let <code>ld</code> know which data changes when the sections are
 | 
						|
relocated, and how to change that data, <span class="command">as</span> also writes to the
 | 
						|
object file details of the relocation needed.  To perform relocation
 | 
						|
<code>ld</code> must know, each time an address in the object
 | 
						|
file is mentioned:
 | 
						|
     <ul>
 | 
						|
<li>Where in the object file is the beginning of this reference to
 | 
						|
an address? 
 | 
						|
<li>How long (in bytes) is this reference? 
 | 
						|
<li>Which section does the address refer to?  What is the numeric value of
 | 
						|
     <pre class="display">          (<var>address</var>) − (<var>start-address of section</var>)?
 | 
						|
     </pre>
 | 
						|
     <li>Is the reference to an address “Program-Counter relative”? 
 | 
						|
</ul>
 | 
						|
 | 
						|
   <p><a name="index-addresses_002c-format-of-190"></a><a name="index-section_002drelative-addressing-191"></a>In fact, every address <span class="command">as</span> ever uses is expressed as
 | 
						|
<pre class="display">     (<var>section</var>) + (<var>offset into section</var>)
 | 
						|
</pre>
 | 
						|
   <p class="noindent">Further, most expressions <span class="command">as</span> computes have this section-relative
 | 
						|
nature. 
 | 
						|
(For some object formats, such as SOM for the HPPA, some expressions are
 | 
						|
symbol-relative instead.)
 | 
						|
 | 
						|
   <p>In this manual we use the notation {<var>secname</var> <var>N</var>} to mean “offset
 | 
						|
<var>N</var> into section <var>secname</var>.”
 | 
						|
 | 
						|
   <p>Apart from text, data and bss sections you need to know about the
 | 
						|
<dfn>absolute</dfn> section.  When <code>ld</code> mixes partial programs,
 | 
						|
addresses in the absolute section remain unchanged.  For example, address
 | 
						|
<code>{absolute 0}</code> is “relocated” to run-time address 0 by
 | 
						|
<code>ld</code>.  Although the linker never arranges two partial programs'
 | 
						|
data sections with overlapping addresses after linking, <em>by definition</em>
 | 
						|
their absolute sections must overlap.  Address <code>{absolute 239}</code> in one
 | 
						|
part of a program is always the same address when the program is running as
 | 
						|
address <code>{absolute 239}</code> in any other part of the program.
 | 
						|
 | 
						|
   <p>The idea of sections is extended to the <dfn>undefined</dfn> section.  Any
 | 
						|
address whose section is unknown at assembly time is by definition
 | 
						|
rendered {undefined <var>U</var>}—where <var>U</var> is filled in later. 
 | 
						|
Since numbers are always defined, the only way to generate an undefined
 | 
						|
address is to mention an undefined symbol.  A reference to a named
 | 
						|
common block would be such a symbol: its value is unknown at assembly
 | 
						|
time so it has section <em>undefined</em>.
 | 
						|
 | 
						|
   <p>By analogy the word <em>section</em> is used to describe groups of sections in
 | 
						|
the linked program.  <code>ld</code> puts all partial programs' text
 | 
						|
sections in contiguous addresses in the linked program.  It is
 | 
						|
customary to refer to the <em>text section</em> of a program, meaning all
 | 
						|
the addresses of all partial programs' text sections.  Likewise for
 | 
						|
data and bss sections.
 | 
						|
 | 
						|
   <p>Some sections are manipulated by <code>ld</code>; others are invented for
 | 
						|
use of <span class="command">as</span> and have no meaning except during assembly.
 | 
						|
 | 
						|
   </body></html>
 | 
						|
 |