JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Solaris 64-bit Developer's Guide
search filter icon
search icon

Document Information


1.  64-bit Computing

2.  When to Use 64-bit

3.  Comparing 32-bit Interfaces and 64-bit Interfaces

4.  Converting Applications

5.  The Development Environment

6.  Advanced Topics

SPARC V9 ABI Features

Stack Bias

Address Space Layout of the SPARC V9 ABI

Placement of Text and Data of the SPARC V9 ABI

Code Models of the SPARC V9 ABI

AMD64 ABI Features

Address Space Layout for amd64 Applications

Alignment Issues

Interprocess Communication

ELF and System Generation Tools

/proc Interface

Extensions to sysinfo(2)

libkvm and /dev/ksyms

libkstat Kernel Statistics

Changes to stdio

Performance Issues

64-bit Application Advantages

64-bit Application Disadvantages

System Call Issues

What Does EOVERFLOW Mean?

Beware ioctl()

A.  Changes in Derived Types

B.  Frequently Asked Questions (FAQs)


SPARC V9 ABI Features

64-bit applications are described using Executable and Linking Format (ELF64), which allows large applications and large address spaces to be described completely.

SPARCV9. The SPARC Compliance Definition, Version 2.4, contains details of the SPARC V9 ABI. It describes the 32-bit SPARC V8 ABI and the 64-bit SPARC V9 ABI. You can obtain this document from SPARC International at

Following is a list of the SPARC V9 ABI features.

Stack Bias

SPARCV9. An important feature of the SPARC V9 ABI for developers is the stack bias. For 64-bit SPARC programs, a stack bias of 2047 bytes must be added to both the frame pointer and the stack pointer to get to the actual data of the stack frame. See the following figure.

Diagram showing the addition of 2047 bytes of stack bias for a 64-bit SPARC program

For more information on stack bias, please see the SPARC V9 ABI.

Address Space Layout of the SPARC V9 ABI

SPARCV9. For 64-bit applications, the layout of the address space is closely related to that of 32-bit applications, though the starting address and addressing limits are radically different. Like SPARC V8, the SPARC V9 stack grows down from the top of the address space, while the heap extends the data segment from the bottom.

The diagram below shows the default address space provided to a 64–bit application. The regions of the address space marked as reserved might not be mapped by applications. These restrictions might be relaxed on future systems.

Diagram showing address space allocation for a typical SPARCV9 64-bit application

The actual addresses in the figure above describe a particular implementation on a particular machine, and are given for illustrative purposes only.

Placement of Text and Data of the SPARC V9 ABI

By default, 64-bit programs are linked with a starting address of 0x100000000. The whole program is above 4 gigabytes, including its text, data, heap, stack, and shared libraries. This helps ensure that 64-bit programs are correct by making it so the program will fault in the lower 4 gigabytes of its address space, if it truncates any of its pointers.

While 64-bit programs are linked above 4 gigabytes, you can still link them below 4 gigabytes by using a linker mapfile and the -M option to the compiler or linker. A linker mapfile for linking a 64-bit SPARC program below 4 gigabytes is provided in /usr/lib/ld/sparcv9/map.below4G.

See the ld(1) linker man page for more information.

Code Models of the SPARC V9 ABI

SPARCV9. Different code models are available from the compiler for different purposes to improve performance and reduce code size in 64-bit SPARC programs. The code model is determined by the following factors:

The following table describes the different code models available for 64-bit SPARC programs.

Table 6-1 Code Model Descriptions: SPARCV9

Code Model
Code Size
External Object Reference Model
< 2 gigabytes
Low (low 32 bits of address space)
< 2 gigabytes
Middle (low 44 bits of address space)
< 2 gigabytes
< 2 gigabytes
Small (<= 1024 external objects)
< 2 gigabytes
Large (<= 2**29 external objects)

Shorter instruction sequences can be achieved in some instances with the smaller code models. The number of instructions needed to do static data references in absolute code is the fewest for the abs32 code model and the most for the abs64 code model, while abs44 is in the middle. Likewise, the pic code model uses fewer instructions for static data references than the PIC code model. Consequently, the smaller code models can reduce the code size and perhaps improve the performance of programs that do not need the fuller functionality of the larger code models.

To specify which code model to use, the -xcode=<model> compiler option should be used. Currently, for 64–bit objects, the compiler uses the abs64 model by default. You can optimize your code by using the abs44 code model; you will use fewer instructions and still cover the 44-bit address space that the current UltraSPARC platforms support.

See the SPARC V9 ABI and compiler documentation for more information on code models.

Note - A program compiled with the abs32 code model must be linked below 4 gigabytes using the -M /usr/lib/ld/sparcv9/map.below4G option.