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

Preface

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)

Index

System Call Issues

The following sections discuss system call issues.

What Does EOVERFLOW Mean?

The EOVERFLOW return value is returned from a system call whenever one or more fields of the data structure used to pass information out of the kernel is too small to hold the value.

A number of 32-bit system calls now return EOVERFLOW when faced with large objects on the 64-bit kernel. While this was already true when dealing with large files, the fact that daddr_t, dev_t, time_t, and its derivative types struct timeval and timespec_t now contain 64-bit quantities might mean more EOVERFLOW return values are observed by 32-bit applications.

Beware ioctl()

Some ioctl(2) calls have been rather poorly specified in the past. Unfortunately, ioctl() is completely devoid of compile-time type checking; therefore, it can be a source of bugs that are difficult to track down.

Consider two ioctl() calls—one that manipulates a pointer to a 32-bit quantity (IOP32), the other that manipulates a pointer to a long quantity (IOPLONG).

The following code sample works as part of a 32-bit application:

    int a, d;
    long b;
    ...
    if (ioctl(d, IOP32, &b) == -1)
            return (errno);
    if (ioctl(d, IOPLONG, &a) == -1)
            return (errno);

Both ioctl(2) calls work correctly when this code fragment is compiled and run as part of a 32-bit application.

Both ioctl() calls also return success when this code fragment is compiled and run as a 64-bit application. However, neither ioctl() works correctly. The first ioctl() passes a container that is too big, and on a big-endian implementation, the kernel will copy in or copy out from the wrong part of the 64-bit word. Even on a little-endian implementation, the container probably contains stack garbage in the upper 32-bits. The second ioctl() will copy in or copy out too much, either reading an incorrect value, or corrupting adjacent variables on the user stack.