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:

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.

Notes Specific to Mac OS X 10.0 Release

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.

Notes Specific to Mac OS X 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.

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.

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.

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.

 

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).

Known Problems

These bugs are known to exist in the compiler tools:


Reference

1670513

Problem

4.4BSD ar extended format #1 not compatible with compiler tools.

Description

The 4.4 ar command can create an archive with the base name of an object file that is longer than 16 characters. With the -L option, it produces a format that makes the object file in the archive invisible to various tools, including the static link editor. This can lead to undefined symbols when this archive is linked against. Other tools like nm and ranlib also don't see the long-name object files in the archive. To avoid this problem, ar makes the -T option, which truncates names, a default option. The compiler tools will understand the extended format in future releases.

Workaround

Do not use the -L option with ar when creating archive libraries. Use the -T option (the default for the Premier release) to tuncate file names or use libtool -static to create archive libraries.


Reference

1666993

Problem

The Mac OS X assembler is different from ppcasm.

Description

The major difference is that the Mac OS X assembler is not TOC-based and uses two instructions to load a global or static item. The directives and the syntax of labels and directives of the two assemblers are very different. Also, the Mac OS X assembler is stricter in the parameter types and ranges for instructions. For more on this last topic, see "Instruction Parameter Differences," below.

Workaround

The difference between the Mac OS X assembler and the TOC-based model, plus the differences in directives and syntax, may necessitate significant rewriting of assembly code for the Developer Release. The strict parameter requirements might require rewriting of assembly code for the Developer Release but the resulting code should work with ppcasm.


Reference

1670513

Problem

BSD 4.4 ar format is not compatible with compiler tools

Description

The BSD 4.4 ar command, which creates an archive with object file names longer than 16 characters, produces a format that makes the object file invisible to various tools, including the static link editor. This can lead to undefined symbols when a program links against this archive. Other tools like nm and ranlib also don't see the object files with longer names in the archive.

Workaround

Use the -T option with ar to tuncate file names or use libtool -static to create archive libraries.


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.