第6 章• 高级主题55
位置（地址空间中的低、中或任意位置）
外部对象引用模型（小或大）
下表介绍了可用于64 位SPARC 程序中的不同代码模型。
表6–1 代码模型说明：SPARCV9
代码模型可放置性代码大小位置外部对象引用模型
abs32 绝对<2GB 低（低32 位地址
空间）
无
abs44 绝对<2GB 中（低44 位地址
空间）
无
abs64 绝对<2GB 任意位置无
pic PIC（位置无关代
码）
<2GB 任意位置小（<= 1024 个外
部对象）
PIC PIC < 2 GB 任意位置大（<= 2**29 个外
部对象）
在某些情况下，可以使用较小的代码模型实现较短的指令序列。在绝对代码中执行静态数
据引用所需的指令数在不同的代码模型中各不相同：在abs32 代码模型中最少，在abs64 代
码模型中最多，在abs44 代码模型中居于两者之间。同样，在执行静态数据引用时，pic 代
码模型使用的指令比PIC 代码模型使用的要少。因此，代码模型越小，代码块越小，对于
无需利用较大代码模型的更完整功能的程序，还可能会提高其性能。
要指定要使用的代码模型，应使用-xcode= 编译器选项。目前，对于64 位对象，编
译器在缺省情况下使用abs64 模型。通过使用abs44 代码模型可以优化代码，此时将使用较
少的指令，并且仍能涵盖当前的UltraSPARC 平台所支持的44 位地址空间。
有关代码模型的更多信息，请参见SPARC V9ABI 和编译器文档。
注– 对于使用abs32 代码模型编译的程序，必须使用-M /usr/lib/ld/sparcv9/map.below4G
选项将其链接到4GB以下的地址空间。
AMD64ABI 特征
64 位应用程序使用可执行和链接格式(Executable and Linking Format, ELF64) 进行描述，使用
该格式可以全面地描述大型应用程序和较大地址空间。
以下列出了AMDABI 的特征：
AMDABI 允许充分利用所有的64 位指令和64 位寄存器。许多新指令都是对现有i386 指
令集的直接扩展。目前，共有十六个通用寄存器：
AMD64ABI 特征
56 Solaris（64 位）开发者指南• 2006 年11 月
七个通用寄存器（%rdi、%rsi、%rdx、%rcx、%r8、%r9 和%rax）在函数调用序列中具有
明确定义的角色，该序列现在用于在寄存器中传递参数。
两个寄存器（%rsp 和%rbp）用于管理栈。
两个寄存器（%r10 和%r11）是临时寄存器。
五个寄存器（%r12、%r13、%r14、%r15 和%rbx）由被调用方保存。
对于AMDABI，基本函数调用的约定不同。参数会放在寄存器中。对于简单的整数参
数，前几个参数依次放在%rdi、%rsi、%rdx、%rcx、%r8 和%r9 寄存器中。
对于AMD，栈的布局稍有不同。具体来说，栈在紧靠调用指令的前面始终以16 个字节
为边界对齐。
指令大小仍为32 位。因此，生成地址常量需要更多指令。由于调用指令只能到达从
%rip 加/减2GB的范围，因此无法再将其用于在地址空间中的任何位置建立分支。
现在，整数乘除函数可以完全在硬件中实现。
结构的传递和返回以不同的方式实现。小型数据结构和某些浮点参数现在直接在寄存器
中传递。
使用新的PC 相关寻址模式，可以生成更高效的位置无关代码。
所有数据类型现在都与其长度对齐。
许多基本派生类型会更长，因此，许多系统调用接口数据结构现在具有不同的长度。
系统中存在两组不同的库：一种用于32 位i386 应用程序的库，另一种用于64 位amd64
应用程序的库。
AMDABI 极大地增强了浮点功能。
通过64 位ABI，可以使用所有使用x87 浮点寄存器（%fpr0 至%fpr7，%mm0 至%mm7）的
x87 和MMX指令。
此外，还可以使用那些使用128 位XMM寄存器（%xmm0 至%xmm15）完整SSE 和SSE2 指
令集。
请参见amd64 psABI 草案文档《System VApplication Binary Interface,AMD64Architecture
Processor Supplement》（草案版本0.92）。
amd64 应用程序的地址空间布局
对于64 位应用程序，尽管起始地址和寻址限制大不相同，但地址空间的布局与32 位应用程
序的布局密切相关。与SPARC V9 一样，amd64 栈从地址空间的顶部开始减小，而堆则从底
部开始扩展数据段。
下图说明了为64 位应用程序提供的缺省地址空间。地址空间中标记为保留空间的区域可能
不是由应用程序进行映射。这些限制在将来的系统中可能会有所放松。
AMD64ABI 特征
第6 章• 高级主题57
上图中的实际地址描述了特定计算机上的特定实现，仅供参考。
对齐问题
还有一个问题也与数据结构中32 位long long 元素的对齐相关；i386 应用程序仅以32 位为
边界将long long 元素对齐，而amd64 ABI 则限制long long 元素以64 位为边界，这有可能
会在数据结构中产生更宽的空白区域。这与SPARC 中有所不同，在SPARC 中32 位或64 位
long long 项均以64 位为边界对齐。
下表说明了指定体系结构中的数据类型对齐情况。
表6–2数据类型对齐
体系结构long long double long double
i386 4 4 4
amd64 8 8 16
sparcv8 8 8 8
sparcv9 8 8 16
针对SPARC 系统，尽管看起来已经是干净的64 位代码，但是如果在32 位和64 位编程环境
之间复制数据结构，则这两个环境中不同的对齐情况可能会产生问题。这些编程环境包括
对齐问题
58 Solaris（64 位）开发者指南• 2006 年11 月
设备驱动程序的ioctl 例程、doors 例程或其他IPC 机制。通过对这些接口仔细进行编码，
并且谨慎地使用#pragma pack 或_Pack 指令，可避免对齐问题。
进程间通信
以下进程间通信(interprocess communication, IPC) 元语仍适用于64 位和32 位进程之间的通
信。
System V IPC 元语，如shmop(2)、semop(2) 和msgsnd(2)
mmap(2)（针对共享文件调用）
pipe(2)（在进程之间使用）
door_call(3DOOR)（在进程之间使用）
rpc(3NSL)（在使用xdr(3NSL) 中所述的外部数据表示形式的同一台或不同计算机上的进
程之间使用）
尽管所有这些元语都允许在32 位和64 位进程之间进行通信，但是可能需要明确执行一些步
骤来确保在进程间交换的数据可以由所有这些元语正确解释。例如，两个进程共享由C 数
据结构所描述的数据，并且该数据结构中包含类型为long 的变量，如果不了解32 位进程将
该变量视为4 字节值，而64 位进程将该变量视为8 字节值，则在这两个进程之间交换的数
据将无法正确解释。
处理此差异的一种方法是确保数据在这两个进程中具有完全相同的长度和含义。构建使用
定宽类型（如int32_t 和int64_t）的数据结构。处理对齐问题时仍需要小心。对于共享数
据结构，可能需要对其进行填充，或者使用编译器指令（如#pragma pack 或_Pack）对其重
新打包。请参见第58 页中的“对齐问题”。
中提供了用于镜像系统派生类型的派生类型系列。这些类型的符号和长度
与32 位系统的基本类型相同，但是按照特定方式进行定义，以便长度在ILP32 和LP64 编译
环境中保持不变。
在32 位和64 位进程之间共享指针极为困难。显然，指针长度不同，但更重要的是，尽管在
现有的C 用法中有一个64 位整数值(long long)，但是64 位指针在32 位环境中没有等效指
针。为了使64 位进程可以与32 位进程共享数据，必须使32 位进程一次最多只能查看4GB
共享数据。
XDR 例程xdr_long(3NSL) 可能是一个问题，但是，在线上仍然会将其作为32 位值进行处
理，以便与现有协议兼容。如果要求该例程的64 位版本对不适合32 位值的long 值进行编
码，则编码操作将失败。
进程间通信
第6 章• 高级主题59
ELF 和系统生成工具
64 位二进制对象存储在ELF64 格式的文件中，此格式与ELF32 格式非常相似，不同的是大
多数字段都已增大，可以适应所有的64 位应用程序。ELF64 文件可以使用elf(3ELF) API
（例如elf_getarhdr (3ELF)）进行读取。
32 位和64 位版本的ELF 库elf(3ELF) 可同时支持ELF32 格式和ELF64 格式及其对应的API。
这允许应用程序从32 位或64 位系统（尽管64 位系统仍需执行64 位）生成、读取或修改这
两种文件格式。
此外，Solaris 还提供了一组GELF（常规ELF）接口，以便允许程序员使用一个单独的公用
API 来处理这两种格式。请参见elf(3ELF)。
所有的系统ELF 实用程序（包括ar(1)、nm(1)、ld(1) 和dump(1)）均已进行更新，可以接受
这两种ELF 格式。
/proc 接口
/proc 接口可供32 位和64 位应用程序使用。32 位应用程序可以检查和控制其他32 位应用程
序的状态。因此，可以使用现有的32 位调试器来调试32 位应用程序。
64 位应用程序可以检查和控制32 位或64 位应用程序。但是，32 位应用程序无法控制64 位
应用程序，因为32 位API 不允许描述64 位进程的完整状态。因此，必须使用64 位调试器
才能调试64 位应用程序。
sysinfo(2) 的扩展
使用Solaris S10 操作环境中新的sysinfo(2) 子代码，应用程序可确定有关可用指令集体系结
构的更多信息。
SI_ARCHITECTURE_32
SI_ARCHITECTURE_64
SI_ARCHITECTURE_K
SI_ARCHITECTURE_NATIVE
例如，对于系统中可用的64 位ABI 的名称（如果有），可以通过使用SI_ARCHITECTURE_64
子代码来对其进行使用。有关详细信息，请参见sysinfo(2)。
ELF 和系统生成工具
60 Solaris（64 位）开发者指南• 2006 年11 月
libkvm 和/dev/ksyms
64 位版本的Solaris 系统是使用64 位内核实现的。直接检查或修改内核中内容的应用程序必
须转换为64 位应用程序，并且必须与64 位版本的库链接。
执行此转换和清理工作之前，应当考虑为什么应用程序需要首先直接查看内核数据结构。
可能是由于在此过程中首先会导入或创建程序，因此Solaris 平台上将启用用来提取系统调
用所需数据的其他接口。请参见sysinfo(2)、kstat(3KSTAT)、sysconf(3C) 和proc(4)，这
些接口是最常见的替换API。如果可以使用这些接口来替代kvm_open(3KVM)，请使用它们
并使应用程序保持32 位以实现最大可移植性。另一个益处是其中的大多数API 可能更快，
并且可能不要求访问内核内存所需的相同安全权限。
如果尝试针对64 位内核或崩溃转储使用kvm_open(3KVM)，则32 位版本的libkvm 会返回失
败信息。同样，如果尝试针对32 位内核崩溃转储使用kvm_open (3KVM)，则64 位版本的
libkvm 也会返回失败信息。
因为内核是一个64 位程序，所以用来打开/dev/ksyms 以直接检查内核符号表的应用程序需
要进行增强，以便可以识别ELF64 格式。
无法明确判断kvm_read() 或kvm_write() 的地址参数应该是内核地址还是用户地址这一问
题对于64 位应用程序和内核更加严重。所有使用libkvm 并且还使用kvm_read() 和
kvm_write() 的应用程序应当转换为使用相应的kvm_read()、kvm_write()、kvm_uread() 和
kvm_uwrite() 例程。（这些例程最初是在Solaris 2.5 中提供的。）
尽管直接读取/dev/kmem 或/dev/mem 的应用程序尝试解释从这些设备中读取的数据可能会
出错，但这些应用程序仍可以运行；32 位和64 位内核之间的数据结构偏移量和长度几乎肯
定是不相同的。
libkstat 内核统计信息
许多内核统计信息的大小与内核是64 位还是32 位程序完全无关。通过指定的kstats（请参
见kstat(3KSTAT)）导出的数据类型是自述性类型，可用来导出带符号或无符号并且具有相
应标记的32 位或64 位计数器数据。因此，使用libkstat 的应用程序无需转换为64 位应用
程序即可成功处理64 位内核。
注– 如果要修改的设备驱动程序用来创建和维护指定的kstats，则应当尝试使用定宽统计信
息类型，使所导出的统计信息的大小在32 位和64 位内核之间保持不变。
libkstat 内核统计信息
第6 章• 高级主题61
stdio 的更改
在64 位环境中，已经对stdio 功能进行了扩展，允许同时打开256 个以上的流。32 位stdio
功能仍具有最多只能同时打开256 个流这一限制。
64 位应用程序不应当依赖具有对FILE 数据结构成员的访问权限。如果尝试直接访问特定于
实现的专用结构成员，则可能会导致编译错误。现有的32 位应用程序不会受到此更改的影
响，但是，在任何代码中都不应当再直接使用这些结构成员。
FILE 结构有很长的历史，只有少数应用程序曾经查看过数据结构内部以收集有关流状态的
其他信息。由于64 位版本的FILE 结构现在是不透明的，因此，32 位libc 和64 位libc 中
均已添加了一系列新例程，以允许在不依赖内部实现的情况下检查同一个状态。例如，请
参见__fbufsize(3C)。
性能问题
以下几节将讨论64 位性能的优缺点。
64 位应用程序的优点
针对64 位值更高效地执行算术和逻辑运算。
运算过程使用全寄存器集宽度、全寄存器集和新指令。
64 位值的参数传递效率更高。
小型数据结构和浮点值的参数传递效率更高。
提供了额外的整数寄存器和浮点寄存器。
对于amd64，提供了PC 相关寻址模式，从而可提高位置无关代码的执行效率。
64 位应用程序的缺点
64 位应用程序需要更多的栈空间才能容纳更大的寄存器。
由于使用了更大的指针，因此应用程序需要更大的高速缓存。
64 位应用程序不能在32 位平台上运行。
系统调用问题
以下几节将讨论系统调用问题。
EOVERFLOW 的含义
每次用来从内核向外传递信息的数据结构中的一个或多个字段太小而无法容纳该值时，系
统调用中便会返回EOVERFLOW 返回值。
stdio 的更改
62 Solaris（64 位）开发者指南• 2006 年11 月
现在，许多32 位系统调用在遇到64 位内核中的大对象时都会返回EOVERFLOW。在处理大文
件时会出现上述情况，由于daddr_t、dev_t、time_t 及其派生类型struct timeval 和
timespec_t 现在包含64 位值，因此这可能意味着32 位应用程序会遇到更多的EOVERFLOW 返
回值。
谨慎使用ioctl()
过去，指定的一些ioctl(2) 调用非常不当。遗憾的是，ioctl() 完全不执行编译时类型检
查，因此，可能难以找到错误的来源。
请考虑使用两个ioctl() 调用：一个用来处理32 位值(IOP32) 的指针，另一个用来处理长值
(IOPLONG) 的指针。
以下代码样例作为32 位应用程序的一部分来运行：
int a, d;
long b;
...
if (ioctl(d, IOP32, &b) == -1)
return (errno);
if (ioctl(d, IOPLONG, &a) == -1)
return (errno);
编译此代码段并将其作为32 位应用程序的一部分运行时，这两个ioctl(2) 调用均可正常工
作。
编译此代码段并将其作为64 位应用程序的一部分运行时，这两个ioctl() 调用也将成功返
回。但是，这两个ioctl() 均无法正常工作。第一个ioctl() 传递的容器太大，并且在大端
字节序实现中，内核将从64 位字的错误部分向外复制数据或向其中复制数据。即使在小端
字节序实现中，该容器也可能在高32 位中包含栈垃圾。第二个ioctl() 会从字中向外复制
或向其中复制过多的数据，从而导致读取错误的值或破坏用户栈上的相邻变量。
系统调用问题
第6 章• 高级主题63
64
派生类型更改
就派生类型及其长度而言，缺省的32 位编译环境与早期发行版的Solaris 操作环境相同。在
64 位编译环境中，有必要对派生类型进行一些更改。以下各表中将重点介绍这些经过更改
的派生类型。
请注意，尽管32 位和64 位编译环境不同，但是它们使用同一组头文件，其相应的定义通过
编译选项确定。为了更好地了解可供应用程序开发者使用的选项，首先了解_ILP32 和
_LP64 功能测试宏会有所帮助。
表A–1功能测试宏
功能测试宏说明
_ILP32 _ILP32 功能测试宏用来指定ILP32 数据模型，该模型中类型为int、long 的
数据和指针是32 位的。如果仅使用该宏，则会使与以前Solaris 实现相同的派
生类型和长度可见。此为生成32 位应用程序时的缺省编译环境，它可确保C
和C++ 应用程序保持完全二进制和源代码兼容。
_LP64 _LP64 功能测试宏用来指定_LP64 数据模型，该模型中类型为int 的数据是32
位的，类型为long 的数据和指针是64 位的。如果是在64 位模式下进行编
译，则缺省情况下会定义_LP64。开发者只需确保在源代码中包括
或，即可使_LP64 定义可见。
以下几个示例说明如何根据编译环境使用功能测试宏来使正确的定义可见。
示例A–1 _LP64 中定义的size_t
#if defined(_LP64)
typedef ulong_t size_t; /* size of something in bytes */
#else
typedef uint_t size_t; /* (historical version) */
A附录A
65
示例A–1 _LP64 中定义的size_t （续）
#endif
使用本示例中的定义生成64 位应用程序时，size_t 是类型为ulong_t 或unsigned long 的数
据（在LP64 模型中是64 位值）。相反，生成32 位应用程序时，size_t 会定义成类型为
uint_t 或unsigned int 的数据（在LP32 或LP64 模型中是32 位值）。
示例A–2 _LP64 中定义的uid_t
#if defined(_LP64)
typedef int uid_t; /* UID type */
#else
typedef long uid_t; /* (historical version) */
#endif
在以上任一示例中，只要ILP32 类型表示形式与LP64 类型表示形式相同，即可获取相同的
最终结果。例如，如果在32 位应用程序环境中将size_t 更改为ulong_t，或者将uid_t 更
改为int，则这些类型仍表示32 位值。但是，保留以前的类型表示形式可确保在32 位C 和
C++ 应用程序中保持一致，并与早期发行版的Solaris 操作环境保持完全二进制兼容和源代
码兼容。
表A–2 列出了已经更改的派生类型。请注意，在向Solaris 软件中添加64 位支持以前，
_ILP32 功能测试宏下面列出的类型与Solaris 2.6 中的类型相匹配。生成32 位应用程序时，
可供开发者使用的派生类型与_ILP32 列中的类型相匹配。生成64 位应用程序时，派生类型
与_LP64 列中所列的类型相匹配。除了wchar_t 和wint_t 类型在 中定义以外，所
有这些类型都在 中定义。
检查这些表时，请记住，在32 位环境中类型为int、long 的数据和指针是32 位的；在64 位
环境中，类型为int 的数据是32 位的，而类型为long 的数据和指针则是64 位的。
表A–2经过更改的常规派生类型
派生类型Solaris 2.6 _ILP32 _LP64
blkcnt_t longlong_t longlong_t long
id_t long long int
major_t ulong_t ulong_t uint_t
minor_t ulong_t ulong_t uint_t
派生类型更改
66 Solaris（64 位）开发者指南• 2006 年11 月
表A–2 经过更改的常规派生类型（续）
派生类型Solaris 2.6 _ILP32 _LP64
mode_t ulong_t ulong_t uint_t
nlink_t ulong_t ulong_t uint_t
paddr_t ulong_t ulong_t 未定义
pid_t long long int
ptrdiff_t int int long
size_t uint_t uint_t ulong_t
ssize_t int int long
uid_t long long int
wchar_t long long int
wint_t long long int
表A–3 列出了特定于大文件编译环境的派生类型。这些类型仅在定义了
_LARGEFILE64_SOURCE 功能测试宏的情况下才会进行定义。请注意，以前的Solaris 2.6 发行版
中保留了ILP32 编译环境。
表A–3经过更改的特定于大文件的派生类型
派生类型Solaris 2.6 _ILP32 _LP64
blkcnt64_t longlong_t longlong_t blkcnt_t
fsblkcnt64_t u_longlong_t u_longlong_t blkcnt_t
fsfilcnt64_t u_longlong_t u_longlong_t fsfilcnt_t
ino64_t u_longlong_t u_longlong_t ino_t
off64_t longlong_t longlong_t off_t
表A–4 列出了经过更改的与_FILE_OFFSET_BITS 值相关的派生类型。对于定义了_LP64 并且
_FILE_OFFSET_BITS==32 的应用程序，不能进行编译。缺省情况下，如果定义了_LP64，则
_FILE_OFFSET_BITS==64。如果定义了_ILP32，但是未定义_FILE_OFFSET_BITS，则缺省情况
下_FILE_OFFSET_BITS==32。这些规则在 头文件中定义。
表A–4 经过更改的FILE_OFFSET_BITS 值的派生类型
派生类型
_ILP32 _FILE_ OFFSET_BITS
==32
_ILP32 _FILE_ OFFSET_BITS
==64
_LP64 _FILE_
OFFSET_BITS==64
ino_t ulong_t u_longlong_t ulong_t
派生类型更改
附录A • 派生类型更改67
表A–4 经过更改的FILE_OFFSET_BITS 值的派生类型（续）
派生类型
_ILP32 _FILE_ OFFSET_BITS
==32
_ILP32 _FILE_ OFFSET_BITS
==64
_LP64 _FILE_
OFFSET_BITS==64
blkcnt_t long longlong_t long
fsblkcnt_t ulong_t u_longlong_t ulong_t
fsfilcnt_t ulong_t u_longlong_t ulong_t
off_t long longlong_t long
派生类型更改
68 Solaris（64 位）开发者指南• 2006 年11 月
常见问题解答(FrequentlyAsked Question,
FAQ)
如何确定系统运行的是32 位还是64 位版本的操作系统？
可以使用isainfo -v 命令来确定操作系统运行的应用程序。该命令会显示一组操作系统支
持的应用程序。有关更多信息，请参见isainfo(1) 手册页。
是否可以在32 位硬件上运行64 位版本的操作系统？
不可以。不能在32 位硬件上运行64 位操作系统。64 位操作系统要求使用64 位MMU（内
存管理单元）和CPU 硬件。
如果要在装有32 位操作系统的系统上运行32 位应用程序，是否需要对该应用程序进行更改
？
不需要。如果应用程序仅在32 位操作系统上执行，则不需要对其进行任何更改或重新编
译。
如果要在装有64 位操作系统的系统上运行32 位应用程序，是否需要对该应用程序进行更改
？
大多数应用程序都可以保留为32 位，并且仍可以在运行64 位操作系统的系统上执行，而无
需对代码进行任何更改或重新编译。对于不需要64 位功能的32 位应用程序可以保留为32
位，以便最大程度地提高可移植性。
如果应用程序使用libkvm(3LIB)，则必须将其重新编译为64 位才可以在运行64 位操作系统
的系统上执行。如果应用程序使用/proc，则可能需要将其重新编译为64 位，否则它无法
识别64 位进程。这是因为描述该进程的现有接口和数据结构不够大，无法包含所涉及的64
位值。
如果要实现64 位功能，需要调用什么程序？
没有专门用来调用64 位功能的程序。要在运行64 位版本操作系统的系统上利用64 位功
能，需要重新生成应用程序。
是否可以在运行64 位操作系统的系统上生成32 位应用程序？
B附录B
69
可以。本机编译和交叉编译模式均受支持。无论系统运行的是32 位版本的操作系统还是64
位版本的操作系统，缺省编译模式均为32 位。
是否可以在运行32 位操作系统的系统上生成64 位应用程序？
可以，但前提是安装了系统头文件和64 位库。但是，不能在运行32 位操作系统的系统上运
行64 位应用程序。
生成和链接应用程序时，是否可以结合使用32 位库和64 位库？
不可以。32 位应用程序必须与32 位库链接，64 位应用程序必须与64 位库链接。如果尝试
使用错误的库版本执行生成和链接操作，则会产生错误。
64 位实现中浮点数据类型的长度是多少？
仅有long 和pointer 类型发生了变化。请参见表4–1。
time_t 有何变化？
time_t 类型仍然是类型为long 的值。在64 位环境中，此类型会增大到64 位。因此，64 位
应用程序将不会出现2038 年问题。
在运行64 位Solaris 操作环境的计算机上，uname(1) 的值是多少？
uname -p 命令的输出没有变化。
是否可以创建64 位XView 或OLIT 应用程序？
不可以。这些库对于32 位环境已经过时，并且不会在64 位环境中继续使用。
为什么/usr/bin/sparcv9/ls 中存在64 位版本的ls？
在常规操作中，无需使用64 位版本的ls。但是，由于在/tmp 和/proc 中可能会创建过大的
文件系统对象而导致32 位ls 无法识别，因此，64 位版本的ls 允许用户对这些对象进行检
查。
常见问题解答(Frequently Asked Question, FAQ)
70 Solaris（64 位）开发者指南• 2006 年11 月
索引
数字和符号
, 27-29
$ORIGIN, 48
, 26-27
64 位库, 17
64 位运算, 17
A
ABI, 请参见SPARC V9ABI
amd64 ABI, 地址空间布局, 57-58
API, 19
D
/dev/ksyms, 61
E
ELF, 60
EOVERFLOW, 62-63
G
GELF（常规ELF）, 60
I
ILP32, 7
ioctl(2), 63
isainfo(1), 20
isalist(1), 21
L
LD_LIBRARY_PATH, 47
libkstat, 61
libkvm, 61
lint, 29-32
LP64, 7
转换原则, 32-40
P
/proc, 7
/proc, 60
/proc 限制, 已定义, 17
S
sizeof, 39
SPARC V9ABI
地址空间布局, 54-55
栈偏移量, 54
stdio, 更改, 62
sysinfo(2), 扩展, 60
71
U
uintptr_t, 28
包
包装
isaexec(3C), 51
/usr/lib/isaexec, 50-51
编
编译器, 46-47
常
常量宏, 28
打
打包
打包原则, 49
库和程序的位置, 48
应用程序命名约定, 49
大
大文件, 7
已定义, 16
大虚拟地址空间, 7
已定义, 16
代
代码模型, 55-56
调
调试, 51-52
符
符号扩展, 33-35
整型提升, 33
转换, 33
格
格式字符串宏, 28-29
互
互操作性问题, 17
兼
兼容性
设备驱动程序, 20
应用程序二进制对象, 20
应用程序源代码, 20
进
进程间通信, 59
库
库, 47
链
链接, 47-48
内
内核内存读取器, 17
索引
72 Solaris（64 位）开发者指南• 2006 年11 月
派
派生类型, 26
数
数据模型
请参见ILP32
另请参见LP64
头
头文件, 45-46
限
限制, 28
指
指针运算, 35
索引
73
74
阅读(794) | 评论(0) | 转发(0) |
