Mac OS X 10.2 Release Notes:
Compiler Tools

PATH Documentation > Release Notes

These notes are for the Mac OS X 10.2 Release of the compiler tools. They contain information about the following topics:

• The Mac OS X Mach-O GNU-based assemblers
• The Mac OS X Mach-O static link editor
• The Mac OS X Mach-O dynamic link editor
• Mach-O object file tools (nm, otool, and so on)

Notes Specific to Mac OS X 10.2 Release

The compiler tools for the MacOS X 10.2 Release must be used with prebound images (executables, and shared libraries) from the MacOS X 10.2 User Release. The compiler tools in MacOS 10.1 will not work with prebound images from with the MacOS X 10.2 User Release. If the 10.1 compiler tools are used on prebound images from the MacOS X 10.2 User Release the compiler tools will generate error messages indicating that the image is a malformed file.

New Features

The dynamic linker now supports weak references and weak dylibs

The dynamic linker now supports weak symbol references and weak dymamic libraries. When creating a binary with the static link editor if all the symbols referenced from a given dependent dynamic library are weak references then the library is marked weak. When the binary is used at execution time and a weak library is missing the dynamic linker will not cause an error. For all weak symbols that are missing execution time the dynamic linker uses zero as their address. This allows a weak symbol's address to be tested for zero at runtime allowing the code to avoid using the weak symbol when it is missing. Binaries that use weak references require a dynamic linker from Mac OS X 10.2 or later.

To indicate a symbol is to be a weak reference the __attribute((weak_import)) is used on the prototype of the symbol. When a binary is created by the static link editor normally the all the undefined symbol references of the object files being linked should be consistent for each undefined symbol. That is all undefined symbols should either be weak or non-weak references. If they are not by default this is treated as an error and can be changed with the ld(1) -weak_reference_mismatches treatment flag (see the ld(1) man page for more details).

Weak referenced symbols and weak libraries are only created in the output by the static link editor, ld(1), when the MACOSX_DEPLOYMENT_TARGET environment variable is set to 10.2. If not a warning is generated when a weak reference would be in the output and it is not marked weak. Note the default for the MACOSX_DEPLOYMENT_TARGET environment variable 10.1 so weak referenced symbols and weak libraries are not created by default. See the ld(1) man page for more information on the MACOSX_DEPLOYMENT_TARGET environment variable.

redo_prebinding can now slide dylibs

The redo_prebinding(1) command now can slide dymamic libraries to new prefered addresses (see the man page for more details).

Notes Specific to Mac OS X 10.1 Release

You must use the 10.1 compiler tools with images (executables, plugins and shared libraries) created with the 10.1 tools. The compiler tools in MacOS 10.0 will not work with images created with the 10.1 compiler tools. If you attempt to use the 10.0 compiler tools on images created with the 10.1 compiler tools, error messages may result indicating that the image is a malformed file.

By default the compiler tools build images using the new two-level namespace binding semantics, which has important consequences for compatibility with Mac OS X 10.0 (see below for more information).

New Features

The following new features have been added to the Compiler Tools for the Mac OS X 10.1 system release.

• The compiler tools now support two-level namespaces for binding undefined references from shared libraries. In flat namespace images, all symbols are referenced globally using a single name table. In two-level namespace images, symbols are referenced by library name and symbol name. This prevents multiple-defined-symbol errors when one image exports the same symbol as another image in the same program. You must rebuild your applications and plugins to take advantage of this feature, and there are compatibility restrictions with Mac OS X 10.0 that you should understand. For more information see the ld(1) man page and the two-level namespace release note.
• The dynamic linker now has API's for doing two-levelnamespace lookups. They are NSAddImage(), NSLookupSymbolInImage() and NSIsSymbolNameDefinedInImage(). For more information see the NSModule(3) man page. [This fixes Apple bug number 2689833.]
• Prebinding is now documented in a release note. [This fixes Apple bug number 2611234.]

Notes Specific to Mac OS X 10.0 Release

• There are no notes specific to the Mac OS X 10.0 release of the compiler tools.

Notes Specific to Mac OS X Public Beta Release

New Features

The following new features have been added to the Compiler Tools since the Mac OS X Developer Release 4.

• The dynamic linker now calls shared library initialization routines in their dependent order (reference number 2441683).
• The new function __initialize_Cplusplus() now can be called from a shared library initialization routine to cause the static C++ objects in the library to be initialized. This allows shared library initialization routines to make use of statically initialized C++ objects (reference number 2441683).
• The dynamic linker now supports module termination functions for all types of images (executables, plugins that are not unloaded and shared libraries). See the decription below as part of the notes specific to Mac OS X Developer preview of module termination functions (reference number 2469527).
• The compiler tools support the new directory layout for MacOS X Public Beta. The new location for Frameworks local to the machine is /MacOSX/Library/Framework (in DP4 and previous releases this was /Local/Library/Frameworks).

Notes Specific to Mac OS X Developer Release 4

• There are no notes specific to the compiler tools for Developer Release 4.

Notes Specific to Mac OS X Developer Release 3

New Features

The following new features have been added to the Compiler Tools since the Mac OS X Developer Release 2.

• The static linker supports removing duplicate debugging information from header files when this information appears in multiple linked object files. This is done with the -Si option to the static link editor and is now the default. To have no symbols stripped when linking use the new -Sn option.

Notes Specific to Mac OS X Developer Release 2

New Features

The following new features have been added to the Compiler Tools since the Mac OS X Developer Preview Release.

• Dynamic shared libraries now can have a dynamic shared library initialization routine (reference number 2367584). This routine is specified to libtool(1) with the new "-init symbol_name" argument. The library initialization routine is called before any symbol is used from the library including C++ static initializers (and #pragma CALL_ON_MODULE_BIND routines). So the code in a library initialization routine or code called by it can not depend on C++ static initializers. Also code in a library initialization routine or code called by it can not call any of the dynamic linker API, <mach-o/dyld.h>, otherwise that could result in more than one library initialization routine being partially executed on the stack.
• The dynamic linker now supports shared library install names that start with "@executable_path/" and substitutes the directory path of the executable for "@executable_path/"when locating the library. This requires a kernel from Mac OS X Developer Release 2 or later. Without that kernel, this feature can only be used if argv[0] is in fact the name of the executable and it is an absolute path or relative to the current directory (contains at a '/' in the argv[0] string).
• The NSLinkModule() API now has an option to cause it to return when there is an error loading the module and a new API NSLinkEditError() to get the error information. To use this the constant NSLINKMODULE_OPTION_RETURN_ON_ERROR needs to be or'ed into the options parameter to NSLinkModule(). Then if NSLinkModule() returns NULL the error information can be retrieved with NSLinkEditError().

  The NSLINKMODULE_OPTION_RETURN_ON_ERROR option is an alternative method to the existing dyld error handling which fits better with a plugin model. With the NSLINKMODULE_OPTION_RETURN_ON_ERROR option, the model for handling errors is to simply return without any changes to the program. To support this model of error handling a new API has been added to allow the programmer to get the error information that the dyld error handlers would normally have gotten. The API is similar to the dyld linkEdit error handler except that all the parameters are passed as pointers to be filled in.

  • extern void NSLinkEditError(
    NSLinkEditErrors *c,
    int *errorNumber,
    const char **fileName,
    const char **errorString);

  The last two parameters return pointers to static buffers allocated in the dynamic linker which get reused on subsequent calls to NSLinkEditError(). The NSLinkEditErrors enum has been extended to include NSLinkEditUndefinedError and NSLinkEditMultiplyDefinedError.

Notes Specific to Mac OS X Developer Preview Release

New Features

The following new features have been added to the Compiler Tools since the Mac OS X Server Release.

• The NSLinkModule() API now can create private modules and the new API NSLookupSymbolInModule() allows symbols to be looked up in a private module. To do this the interface to NSLinkModule() has changed in a compatible way from:
  • extern NSModule NSLinkModule(
    NSObjectFileImage objectFileImage,
    const char *moduleName,
    enum bool bindNow);

  to:

  • extern NSModule NSLinkModule(
    NSObjectFileImage objectFileImage,
    const char *moduleName,
    unsigned long options);

  with the options as follows:

  • #define NSLINKMODULE_OPTION_NONE 0x0
    #define NSLINKMODULE_OPTION_BINDNOW 0x1
    #define NSLINKMODULE_OPTION_PRIVATE 0x2

  The first two are the same as bindNow with a value of FALSE and TRUE. The private options are used to load a private module. The API for getting to the symbols of a NSModule that has been privately linked is:

  • extern NSSymbol NSLookupSymbolInModule(
    NSModule module,
    const char *symbolName);

  Then to get the address of the returned NSSymbol, the existing NSAddressOfSymbol() API can be used.

  The NSUnLinkModule() API is now implemented with enough functionality to make Apache work (reference number 2262020). It currently has the following limitations (to be fixed in future releases):

  • only works for plugins (can only be called on modules that were returned by NSLinkModule).
  • C++ plugins that have a static destructor can't be unloaded. The program will crash in atexit(3) when the unlinked destructor is attempted to be called.
  • Objective-C plugins should not be unloaded. The Objective-C runtime has not been updated to know about unloading and the result is very likely to crash the program.
  • The debugger has not been updated to know about unloading and trying to debug a program that unloads its plugins may confuse or crash the debugger.

  The interface to NSUnLinkModule has changed in a compatible way from:

  • extern enum bool NSUnLinkModule(
    NSModule module,
    enum bool keepMemoryMapped);

  to:

  • extern enum bool NSUnLinkModule(
    NSModule module,
    int options);

  where the options are:

  • #define NSUNLINKMODULE_OPTION_NONE 0x0
    #define NSUNLINKMODULE_OPTION_KEEP_MEMORY_MAPPED 0x1
    #define NSUNLINKMODULE_OPTION_RESET_LAZY_REFERENCES 0x2

  The first two are the same as keepMemoryMapped with a value of FALSE and TRUE. The reset lazy references option allows unloading modules with only call sites to undefined functions (direct calls, not calls through pointers) to not cause an undefined symbol error. Then if a subsequent module is loaded that defines symbols that were previously undefined, the call sites will use the new definitions. This is currently only implemented for PowerPC.

  Support for module termination functions has been added for plugins (only). Currently the compiler pragma CALL_ON_UNLOAD (as well as CALL_ON_LOAD) is not yet implemented to use this feature as intended. A work around can be done in place of having the pragma:

  • void my_term(void)
    {
    /* do module termination */
    }
    /* #pragma CALL_ON_UNLOAD my_term */
    #pragma SECTION data ".section __DATA, __mod_term_func, mod_init_funcs"
    static void (*dummy)(void) = my_term;
    #pragma SECTION data

Notes Specific to Mac OS X Server Release

New Features

The following new features have been added to the Compiler Tools since the Rhapsody Developer Release 2.

• The 4.4bsd ar extended format #1 is now supported by the compiler tools. The default is to use 4.4bsd ar extended format #1 when creating static archives whose member names are longer than 16 characters or have spaces in the name. The tools that create static archives, ar(1), libtool(1) and ranlib(1), all take the options -T (to truncate member names) and -L (to used long member names, the default) (reference 1670513).
• The AltiVec opcodes have been added to the Mac OS X PowerPC assembler. To assemble files with these instructions it requires the option -force_cpusubtype_ALL and then it is the code's responsibility to only use these instructions when the CPU supports them. (references 2237908, 2227999, 2213821, 2004760).
• The header file <mach-o/getsect.h> has been added to the system as the proper place to get the prototypes of the Mach-O routines. (reference 2227839).

There are no Notes Specific to Rhapsody Developer Release 2

Notes Specific to Rhapsody Developer Release

New Features

The following new features have been added to the compiler tools since OPENSTEP 4.2 (NeXT).

• The PowerPC architecture is now supported via the -arch ppc switch.
  
  

Known Problems

These bugs are known to exist in the compiler tools:

Bugs Fixed

The following bug has been fixed:

Reference	none
Problem	Profiling does not work
Description	Bugs were reported when developers tried to compile, run and produce the profiling information for a program. Among these bigs were kernel panics, gprof(1) not understanding the gmon.out format produced, add_profil(2) system call not working, and other problems.

PowerPC Assembly Instruction Parameter Differences

Register names can't be designated with just a number. You must refer to them with their register name. This restriction includes general registers (rN), floating point registers, (fN), condition registers (crN), and segment registers (srN). However, you can refer to special registers by their register number or their special register names. The special register names are in lowercase only (for example, mq, xer, lr, ctr, and dsisr).

For instance, for the ppcasm assember you could code a move from segment register instruction as:

mfsr r24,9 ; ppcasm assembler

But, for the Mac OS X assembler, this same move would be coded as:

mfsr r24,sr9 ; Mac OS X assembler

For instructions that take the value 0 or a register, shown in the processor manual as "(rA|0)", r0 can't be used and 0 must be coded. The Mac OS X assembler generates an error messages in these cases.

Where a numeric value is expected as a parameter, a register name can't be use. For example, the ppcasm assembler allows the following:

lwz r1,r2(r3) ; ppcasm assembler

For Mac OS X, this must be coded as:

lwz r1,2(r3) ; Mac OS X assembler

The Mac OS X assembler generates a warning if branch prediction is coded with an unconditional branch.

The Mac OS X assembler checks all fields for range errors and generates error messages if an expression is out of range. The ppcasm assembler simply uses the low N bits of the expression (where N is the field width) if the value is greater than zero. For example the simplified mnemonic:

inslwi rA,rS,n,b

is equivalent to

rlwimi rA,rS,32-b,b,(b+n)-1

The following code:

inslwi r17,r18,19,20 ; equivalent to rlwimi r17,r18,32-20,20,(20+19)-1

assembles to

rlwimi r17,r18,12,20,6 ; where the low 5 bits (20+19)-1 is 6

with ppcasm. This generates an out-of-range error with the Mac OS X assembler.

For fields less than zero, the ppcasm assembler uses the value of zero. For example, the simplified mnemonic:

clrlslwi rA,rS,b,n

is equivalent to

rlwinm rA,rB,n,b-n,31-b

Thus the following code:

clrlslwi r5,r6,7,8 ; equivalent to rlwinm r5,r6,8,7-8,31-7

assembles to:

rlwinm r5,r6,7,0,24 ; where 7-8 gets turned into 0

with ppcasm. This generates an out-of-range error with the Mac OS X assembler.

All integer expressions in the Mac OS X assembler are signed 32-bit values. Parameters that are 16-bit signed or unsigned immediate values must agree in their upper 16 bits or the assembler generates an out-of-range error message.

For example:

addi r1,r2,0xffff ; out of range for a 16-bit signed immediate

generates the message "Parameter error: expression out of range (parameter 3)".

The addi instruction takes a signed immediate value so it will sign extend its parameter to 32 bits before performing the operation. If the value 0xffffffff is intended, it would be coded as:

addi r1,r2,0xffffffff

If this is half of a two-instruction 32-bit add it should be coded as:

addis r1,0,ha16(expression)
addi r1,r2,lo16(expression)

Many of the simplified mnemonics are implemented as Mac OS X assembler macros (as noted in the listing of PowerPC assembler instructions in the assember manual). Like all macros, the macro is expanded and assembled. This expansion can result in errors that can seem confusing when you look at the coded macro. For example, the simplified mnemonic:

extldi rA,rS,n,b

is equivalent to

rldicr rA,rS,b,n-1 

Thus the following code:

extldi r1,r2,0,2

generates the error message "Parameter error: expression out of range (parameter 4)," which refers to "n-1" or "0-1", or parameter 4 of the expanded macro.

The instruction tlbiex, which has been removed from the PowerPC architecture, is not supported by the Mac OS X assembler. This instruction is assembled by ppcasm.

Copyright © 2002 Apple Computer, Inc.