JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
SPARC Assembly Language Reference Manual     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  SPARC Assembler Syntax

2.  Executable and Linking Format

2.1 Sections

2.1.1 Section Header

2.1.2 Predefined User Sections

2.1.2.1 Creating an .init Section in an Object File

2.1.2.2 Creating a .fini Section in an Object File

2.1.3 Predefined Non-User Sections

2.1.4 Symbol Tables

2.1.5 String Tables

2.2 Locations

2.3 Addresses

2.3.1 Relocation Tables

2.4 Tools

3.  Directives and Pseudo-Operations

4.  Creating Data in Assembler

5.  SPARC Code Models

6.  Writing Functions -- The SPARC ABI

7.  Assembler Inline Functions and __asm Code

A.  Using the Assembler Command Line

B.  A Sample Assembler Program

C.  SPARC Instruction Sets and Mnemonics

Index

2.1 Sections

A section is the smallest unit of an object that can be relocated. Use the elfdump(1) command to inspect the components of an object or executable file generated by the assembler.

The following sections are commonly present in an ELF file:

Sections do not need to be specified in any particular order. The current section is the section to which code is generated.

These sections contain all other information in an object file and satisfy several conditions.

  1. Every section must have one section header describing the section. However, a section header does not need to be followed by a section.

  2. Each section occupies one contiguous sequence of bytes within a file. The section may be empty (that is, of zero-length).

  3. A byte in a file can reside in only one section. Sections in a file cannot overlap.

  4. An object file may have inactive space. The contents of the data in the inactive space are unspecified.

Sections can be added for multiple text or data segments, shared data, user-defined sections, or information in the object file for debugging.


Note - Not all of the component sections need to be present.


2.1.1 Section Header

The section header allows you to locate all of the file sections. An entry in a section header table contains information characterizing the data in a section.

The section header contains a number of fields as described in detail in sys/elf.h and Sections in Oracle Solaris 11.1 Linkers and Libraries Guide. However, only the following fields are of immediate interest to the assembly language programmer because they can be specified in assembler pseudo-operations (directives):

sh_flags

Description: One-bit descriptions of section attributes. Table 2-1 describes the some of the section attribute flags. For details and additional flags, see Sections in Oracle Solaris 11.1 Linkers and Libraries Guide

sh_info

Description: Extra information. The interpretation of this information depends on the section type, as described in . Table 2-2

sh_link

Description: Section header table index link. The interpretation of this information depends on the section type, as described in . Table 2-2

sh_name

Description: Specifies the section name. An index into the section header string table section specifies the location of a null-terminated string.

Table 2-1 Section Attribute Flags

Flag
Default Value
Description
SHF_WRITE
0x1
Contains data that is writable during process execution.
SHF_ALLOC
0x2
Occupies memory during process execution. This attribute is off if a control section does not reside in the memory image of the object file.
SHF_EXECINSTR
0x4
Contains executable machine instructions.
SHF_MASKPROC
0xf0000000
Reserved for processor-specific semantics.

Table 2-2 Section Types Modified by Assembler Pseudo-ops

Name

Value

Description

null
0
Marks section header as inactive.
progbits
1
Contains information defined explicitly by the program.
note
7
Contains information that marks the file.
nobits
8
Contains information defined explicitly by the program; however, a section of this type does not occupy any space in the file.

2.1.2 Predefined User Sections

A section that can be manipulated by the section control directives is known as a user section. You can use the section control directives to change the user section in which code or data is generated. Table 2-3 lists some of the predefined user sections that can be named in the section control directives. For details and additional information, see Special Sections in Oracle Solaris 11.1 Linkers and Libraries Guide

Table 2-3 User Sections In Section Control Directives

Section Name
Description
.bss
Section contains uninitialized read-write data.
.comment
Comment section.
.data & .data1
Section contains initialized read-write data.
.debug
Section contains debugging information.
.fini
Section contains runtime finalization instructions.
.init
Section contains runtime initialization instructions.
.rodata & .rodata1
Section contains read-only data.
.text
Section contains executable text.
.line
Section contains line # info for symbolic debugging.
.note
Section contains note information.

2.1.2.1 Creating an .init Section in an Object File

The .init sections contain codes that are to be executed before the the main program is executed. To create an .init section in an object file, use the assembler pseudo-ops shown in Example 2-1.

Example 2-1 Creating an .init Section

.section ".init"

.align   4

<instructions>

At link time, the .init sections in a sequence of .o files are concatenated into an .init section in the linker output file. The code in the .init section are executed before the main program is executed.

Because the whole .init section is treated as a single function body, it is recommented that the only code added to these sections be in the following form:.

call routine_namenop

The called routine should be located in another section. This will prevent conflicting register and stack usage within the .init sections.

2.1.2.2 Creating a .fini Section in an Object File

.fini sections contain codes that are to be executed after the the main program is executed. To create an .fini section in an object file, use the assembler pseudo-ops shown in Example 2-2.

Example 2-2 Creating an .fini Section

.section ".fini"

.align   4

<instructions>

At link time, the .fini sections in a sequence of .o files are concatenated into a .fini section in the linker output file. The codes in the .fini section are executed after the main program is executed.

Because the whole .fini section is treated as a single function body, it is recommended that the only code added to these section be in the following form:.

call routine_namenop

The called routine should be located in another section. This will prevent conflicting register and stack usage within the .fini sections.

2.1.3 Predefined Non-User Sections

Table 2-4 lists sections that are predefined and not under user control. Therefore, these section names are reserved by the assembler and should be avoided.

Table 2-4 Reserved Sections

Section Name
Description
".dynamic"
Section contains dynamic linking information.
.dynstr
Section contains strings needed for dynamic linking.
.dynsym
Section contains the dynamic linking symbol table.
.got
Section contains the global offset table.
.hash
Section contains a symbol hash table.
.interp
Section contains the path name of a program interpreter.
.plt
Section contains the procedure linking table.
.relname & .relaname
Section containing relocation information. name is the section to which the relocations apply, that is, ".rel.text", ".rela.text".
.shstrtab
String table for the section header table names.
.strtab
Section contains the string table.
.symtab
Section contains a symbol table.

2.1.4 Symbol Tables

A symbol table contains information to locate and relocate symbolic definitions and references. The Oracle Solaris SPARC assembler creates a symbol table section for the object file. It makes an entry in the symbol table for each symbol that is defined or referenced in the input file and is needed during linking. The symbol table is then used by the Oracle Solaris linker during relocation. The section header contains the symbol table index for the first non-local symbol.

A symbol table contains the following information defined by Elf32_Sym and Elf64_Sym in sys/elf.h and Symbol Table Section in Oracle Solaris 11.1 Linkers and Libraries Guide:

st_name

Description: Index into the object file symbol string table. A value of zero indicates the symbol table entry has no name; otherwise, the value represents the string table index that gives the symbol name.

st_value

Description: Value of the associated symbol. This value is dependent on the context; for example, it may be an address, or it may be an absolute value.

st_size

Description: Size of symbol. A value of 0 indicates that the symbol has either no size or an unknown size.

st_info

Description: Specifies the symbol type and binding attributes. Table 2-5 and Table 2-6 describe these values.

st_other

Description: Specifies a symbol's visibility.

st_shndx

Description: Contains the section header table index to another relevant section, if specified. As a section moves during relocation, references to the symbol will continue to point to the same location because the value of the symbol will change as well.

Table 2-5 Symbol Type Attributes ELF32_ST_TYPE and ELF64_ST_TYPE

Value
Type
Description
0
notype
Type not specified.
1
object
Symbol is associated with a data object; for example, a variable or an array.
2
func
Symbol is associated with a function or other executable code. When another object file references a function from a shared object, the link editor automatically creates a procedure linkage table entry for the referenced symbol.
3
section
Symbol is associated with a section. These types of symbols are primarily used for relocation.
4
file
Gives the name of the source file associated with the object file.
13

15

loproc

hiproc

Values reserved for processor-specific semantics.

Table 2-6 shows the symbol binding attributes.

Table 2-6 Symbol Binding Attributes ELF32_ST_BIND and ELF64_ST_BIND

Value
Binding
Description
0
local
Symbol is defined in the object file and not accessible in other files. Local symbols of the same name may exist in multiple files.
1
global
Symbol is either defined externally or defined in the object file and accessible in other files.
2
weak
Symbol is either defined externally or defined in the object file and accessible in other files; however, these definitions have a lower precedence than globally defined symbols.
13

15

loproc

hiproc

Values reserved for processor-specific semantics.

2.1.5 String Tables

A string table is a section which contains null-terminated variable-length character sequences, or strings, in the object file; for example, symbol names and file names. The strings are referenced in the section header as indexes into the string table section.

A string may appear multiple times and may also be referenced multiple times. References to substrings may exist, and unreferenced strings are allowed.