JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Linkers and Libraries Guide     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

Part I Using the Link-Editor and Runtime Linker

1.  Introduction to the Oracle Solaris Link Editors

2.  Link-Editor

3.  Runtime Linker

4.  Shared Objects

Part II Quick Reference

5.  Link-Editor Quick Reference

Part III Advanced Topics

6.  Direct Bindings

7.  Building Objects to Optimize System Performance

8.  Mapfiles

9.  Interfaces and Versioning

10.  Establishing Dependencies with Dynamic String Tokens

11.  Extensibility Mechanisms

Part IV ELF Application Binary Interface

12.  Object File Format

File Format

Data Representation

ELF Header

ELF Identification

Data Encoding

Sections

Section Merging

Special Sections

Ancillary Section

COMDAT Section

Group Section

Capabilities Section

Hash Table Section

Move Section

Note Section

Relocation Sections

Relocation Calculations

SPARC: Relocations

SPARC: Relocation Types

64-bit SPARC: Relocation Types

x86: Relocations

32-bit x86: Relocation Types

x64: Relocation Types

String Table Section

Symbol Table Section

Symbol Values

Symbol Table Layout and Conventions

Symbol Sort Sections

Register Symbols

Syminfo Table Section

Versioning Sections

Version Definition Section

Version Dependency Section

Version Symbol Section

13.  Program Loading and Dynamic Linking

14.  Thread-Local Storage

Part V Appendices

A.  Linker and Libraries Updates and New Features

B.  System V Release 4 (Version 1) Mapfiles

Index

Note Section

A vendor or system engineer might need to mark an object file with special information that other programs can check for conformance or compatibility. Sections of type SHT_NOTE and program header elements of type PT_NOTE can be used for this purpose.

The note information in sections and program header elements holds any number of entries, as shown in the following figure. For 64–bit objects and 32–bit objects, each entry is an array of 4-byte words in the format of the target processor. Labels are shown in Figure 12-6 to help explain note information organization, but are not part of the specification.

Figure 12-5 Note Information

image:ELF note section information.
namesz and name

The first namesz bytes in name contain a null-terminated character representation of the entry's owner or originator. No formal mechanism exists for avoiding name conflicts. By convention, vendors use their own name, such as “XYZ Computer Company,” as the identifier. If no name is present, namesz contains the value zero. Padding is present, if necessary, to ensure 4-byte alignment for the descriptor. Such padding is not included in namesz.

descsz and desc

The first descsz bytes in desc hold the note descriptor. If no descriptor is present, descsz contains the value zero. Padding is present, if necessary, to ensure 4-byte alignment for the next note entry. Such padding is not included in descsz.

type

Provides the interpretation of the descriptor. Each originator controls its own types. Multiple interpretations of a single type value can exist. A program must recognize both the name and the type to understand a descriptor. Types currently must be nonnegative.

The note segment that is shown in the following figure holds two entries.

Figure 12-6 Example Note Segment

image:ELF note section example.

Note - The system reserves note information with no name (namesz == 0) and with a zero-length name (name[0] == '\0'), but currently defines no types. All other names must have at least one non-null character.