AIX链接机制原理解析与实践指南

需积分: 16 157 浏览量更新于2024-07-26 收藏 184KB PDF 举报

AIX Makefile Linking AIX操作系统中的链接机制是编译器和链接器的核心组件之一。了解AIX链接机制的原理和各种链接选项对于开发高效、可靠的应用程序至关重要。本文将详细介绍AIX链接机制的原理、链接选项和实际应用。一、AIX链接机制的原理 AIX链接机制是指将编译后的对象文件链接成可执行文件的过程。在AIX操作系统中，链接机制是由ld命令实现的。ld命令读取makefile文件中的链接选项和对象文件，生成可执行文件。 AIX链接机制主要包括以下几个步骤： 1. 编译：将源代码编译成对象文件。 2. 链接：将对象文件链接成可执行文件。 3. 加载：将可执行文件加载到内存中。二、AIX链接选项 AIX链接机制提供了多种链接选项，用于控制链接过程。常见的链接选项包括： * -l：指定库文件的名称。 * -L：指定库文件的搜索路径。 * -o：指定输出文件的名称。 * -s：删除符号表和重定位节。 * -r：生成可重定位的对象文件。三、AIX链接机制的实现 AIX链接机制的实现主要包括以下几个部分： 1. 动态链接：AIX操作系统支持动态链接，允许在运行时加载库文件。 2. 延迟加载：AIX操作系统支持延迟加载，仅在需要时加载库文件。 3. 符号重绑定：AIX操作系统支持符号重绑定，允许在链接时重定位符号。 4. 可执行文件重链接：AIX操作系统支持可执行文件重链接，允许在链接时重新生成可执行文件。四、AIX Makefile链接 AIX Makefile链接是指在Makefile文件中指定链接选项和对象文件，以生成可执行文件。AIX Makefile链接的优点包括： * 提高编译效率：AIX Makefile链接可以减少编译时间，提高编译效率。 * 提高代码可读性：AIX Makefile链接可以生成清晰的编译日志，提高代码可读性。五、AIX C++链接 AIX C++链接是指在AIX操作系统中使用C++语言进行链接。AIX C++链接的特点包括： * 支持C++语言：AIX操作系统支持C++语言，允许使用C++语言进行编译和链接。 * 支持模板元编程：AIX操作系统支持模板元编程，允许使用模板元编程进行编译和链接。六、结论 AIX链接机制是AIX操作系统中的核心组件之一，提供了多种链接选项和机制，以满足不同的应用需求。了解AIX链接机制的原理和各种链接选项对于开发高效、可靠的应用程序至关重要。本文为读者提供了AIX链接机制的详细介绍，希望能够对读者有所帮助。

Page 12

a symbol that is still being used when an attempt is made to unload the module with the

dlclose() call.

It is possible to rebind the definitions of system library symbols as well. For example, an

application can define its own malloc() to override or extend the functionality of the

system defined malloc() in libc.a. To do this, the defining shared module (in this case

shr.o in libc.a) has to be rebuilt using rtl_enable so that the references internal to the

module become hookable. Once this is done, run-time linker is able to override all

references to malloc(). Without rebuilding libc.a via rtl_enable, the internal workings of

libc.a remain "tight" and cannot be rebound.

Several C++ applications overload system functions such as new and delete. This can be

accomplished using the rebinding features of the linker. Please refer to Example 10.

Note: stripped executables cannot be rebound.

Re-linking Executables with Modified Object Files

In AIX the binder can accept both object files and executables as input. This means that

the user has the ability to rebind an existing executable to replace a single modified

object file instead of building a new executable from scratch. No other major UNIX

implementation offers this feature.

In other UNIX systems, the input to the ld command is a set of files containing object

code, either from individual object files or from libraries. The ld command then resolves

the external references among these files and writes an executable with the default name

of a.out. If a bug is found in one of the modules that was included in the a.out file, the

defective source code is modified and recompiled, and then the entire ld process must be

repeated, starting from the full set of object files and libraries.

Since the binding process consumes storage and processor cycles according to the

number of files being accessed and references resolved, rebinding an executable with the

new version of a module is quicker than binding it from scratch.

To pre-bind a library, the following command can be used on the archive file:

ld -r libbar.a -o libbar.o

The compile and bind of a FORTRAN file file1.f would be:

xlf file1.f libbar.o

(Note the use of libbar.o as an ordinary object file, and not with the usual library

identification syntax -lbar.)

To recompile the module and rebind the executable after fixing a bug:

Page 13

xlf file1.f a.out

(Note that if the bug fix resulted in a call to a different subroutine in the library, the bind

would fail.)

Another example:

xlc -c file1.c

The executable mynewapp can be quickly built in this way:

xlc -o mynewapp file1.o myapp -llibraries

The old file1 is still in mynewapp, but the new file1 will be referenced from it, because

the linker will find the new file1 definition first.

Lazy Loading

Lazy loading is a mechanism for deferring the loading of modules until one of its

functions is executed. At this time this capability has limited use for AIX applications

developed natively, but could be useful in some cases where the application is ported

from other platforms.

As an example, if main() calls foo() and foo() is in the shared module libfoo.so, then

libfoo.so is a candidate for lazy loading. If foo() is never called then libfoo.so need not

be loaded at all. If foo() is called, the lazy loading code executes the load() function to

load libfoo.so, patches a function descriptor to make sure subsequent calls simply go

directly to the function itself, then invokes the called function. If for some reason the

module cannot be loaded, the lazy-loader's error-handler is invoked.

By default, the system loader automatically loads all of the module's dependents at the

same time. This occurs because a list of the dependent modules is saved in the loader

section of the module at link-time (the dump -H <filename> command can be used to

view this information). By linking a module with the -blazy option, it is possible to

enable the loading of only the needed dependents. Please note that if the -brtl option is

specified, the -blazy option is ignored and lazy loading is not enabled. This means that

any module linked with the -brtl option to enable run-time linking cannot have its

dependents lazy-loaded. Also, only those modules will be lazy-loaded which are being

referenced for their functions only. If variables in the module are being referenced, the

module is loaded in the normal way. Since lazy loading does not work for run-time

enabled modules, it has significance and used only for the modules that are built using

import lists to identify the undefined symbols. Refer to Example 8 for an illustration.

By using lazy loading, the loading performance of a program can be improved if most of

a module's dependents are never actually used. Every function call to a lazy-loaded

module has an additional overhead of about seven instructions and the first call to a

Page 14

function requires loading the defining module and modifying the function call.

Therefore, if a module calls the functions in most of its dependents, the appropriateness

of enabling lazy loading should be carefully considered.

Please note that a program that compares function pointers might not work correctly

when lazy loading is used because a single function can have multiple addresses. In

particular, if module A calls function f in module B, and if lazy loading of module B was

specified when module A was linked, then the address of f computed in module A differs

from the address of f computed in other modules. Thus, when using lazy loading, two

function pointers might not be equal even if they point to the same function. Also, if any

modules are loaded with relative path names and if the program changes working

directories, the dependent module might not be found when it needs to be loaded. When

using lazy loading, only absolute path names should be used to refer to dependent

modules at link-time.

Since lazy loading works only with conventional style linking on AIX, individual

modules that are: mostly self-contained, referred for function symbols only, and have a

low probability of being loaded anyway should only be considered for lazy loading. The

decision to enable lazy loading is made at link-time on a module-by-module basis. In a

single program it is possible to mix modules that use lazy loading with modules that do

not.

Symbol Resolution on AIX

Now that dynamic loading, run-time linking, and a general understanding of the shared

library architecture on AIX have been introduced, it will be helpful to delve deeper into

the exact mechanism for symbol resolution on AIX. In general, symbol resolution

happens at link-time on AIX. While the actual binding does not happen till load-time, the

export/import interface offers a “promise” to the loader that the imported symbols will be

available from the specified library when they are needed. Run-time linking merely

delays resolution of all undefined symbols that the system loader cannot ignore, until

load-time of the shared modules.

At load-time these undefined symbols are resolved by searching among the exported

symbols of all linked-in shared modules and are marked as being imported from ".." in

the module's symbol table (the symbol table can be listed by using the

dump -HTv

command). Symbols could also be marked as deferred by listing them as

being defined by "#!", followed by the name of the symbol in the import list. This list is

then used to build the shared object that refers to this symbol.

References to deferred symbols are ignored by the run-time linker, so resolution of these

symbols must be performed by the system loader either via a call to loadbind() or by

loading a new module explicitly with load() or dlopen() calls. Deferred imports (also

called anonymous imports) are listed as having "[noIMPid]" as their import ID in the

symbol table section of the

dump -HTv <file name>

output. Refer to Examples 2 and

剩余67页未读，继续阅读

xzmagicc

粉丝: 2
资源: 16

AIX链接机制原理解析与实践指南

makefile的例子FOR AIX

AIX上的makefile编写

makefile makefile makefile

snmp++v3.2.23在aix5下的makefile

Makefile

makefile

AIX平台RS6000程序编译与Makefile指南

2021中国白酒消费洞察白皮书.pdf

基于SpringBoot+Vue3的轻量级通用后台管理系统设计源码

【数字信号分解】基于matlab经验小波变换EWT数字信号分解【含Matlab源码 期】.zip

最新资源

【数字信号分解】基于matlab经验小波变换EWT数字信号分解【含Matlab源码期】.zip