MacOS X 10.2 Release Copyright 2002 by Apple Computer, Inc. All Rights Reserved.

Private MacOS X 10.2 Release Notes:
Compiler Tools (cctools-435)

This file contains release notes for the 5.10 release of the Compiler Tools for the MacOS X 10.2 Release. This file contains information about the following topics:

 

Notes Specific to Release 5.10 (Mac OS X 10.2)

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 and the redo_prebinding(3) API now can slide dymamic libraries to new prefered addresses (see the man page for more details).

Support for weak definitions in coalesced sections

There is now support for the .weak_definition symbol_name assembler directive for symbols in a coalesced section. This is used by the C++ compiler to support explicit template instantiation. The assembler symtax for this is:

.section __TEXT, __template, coalesced
.private_extern _template_func
.weak_definition _template_func
_template_func:
li r3,1
blr

The compiler uses a coalesced section with the .weak_definition directive for implicitly instantiated templates. And uses a regualr section (.text, .data, etc) for an explicit template instantiation.

The static link editor then discards all of the copies of a weak symbol in a coalesced section if the same symbol is defined in another section. If there exists only definitions of the weak symbols in a coalesced section then the one from the first object file being linked will be used and the others will be discarded.

The support for flat namespace images using weak symbols from a coalesced section is likely to be buggy as the semantics for it and lazy binding are not well defined.

Changes since the last releases (cctools-434 for the 5.10 MacOS 10.2 release)
Changes since the last releases (cctools-433 for the 5.10 MacOS 10.2 release)
Changes since the last releases (cctools-432 for the 5.10 MacOS 10.2 release)
Changes since the last releases (cctools-431 for the 5.10 MacOS 10.2 release)
Changes since the last releases (cctools-430 for the 5.10 MacOS 10.2 release)
Changes since the last releases (cctools-427,8,9 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-426 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-425 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-424 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-423 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-422 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-421 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-420 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-419 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-418 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-417 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-416 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-415 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-414 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-413 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-412 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-411 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-410 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-409 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-408 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-407 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-406 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-405 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-404 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-403 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-402 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-401 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-400 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-399 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-398 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-397 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-396 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-395 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-394 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-393 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-392 for the 5.10 MacOS 10.2 release)
=Changes since the last release (cctools-391 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-390 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-389 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-388 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-387 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-386 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-385 for the 5.10 MacOS 10.2 release)
Changes since the last release (cctools-384 for the 5.9 MacOS 10.1 release)

Notes Specific to Release 5.9 (MacOS X 10.1)

New Features

Two level namespace

Work on the compiler tools to support two level name space is now complete and -twolevel_namespace is now the default (Radar bugs 2372124 and 2415916). See the Public release notes for the details.

Changes since the last release (cctools-383 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-382 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-381 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-380 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-379 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-378 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-377 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-376 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-375 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-374 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-373 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-372 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-371 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-370 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-369.3 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-369.2 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-369.1 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-369 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-368 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-367 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-366 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-365 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-364 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-363 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-362 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-361 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-360 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-359 for the 5.9 MacOS 10.1 release)
Changes since the last release (cctools-358 for the 5.8 MacOS 10.0 release)

Notes Specific to Release 5.8 (MacOS X 10.0)

New Features

Two level namespace

Work on the compiler tools to support two level name space is in progress (Radar bugs 2372124 and 2415916). Even though some object file constants and command line options exist they should not be used and are for development purposes only. Do not expect any of this to work at all.

Changes since the last release (cctools-357 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-356 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-355 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-354 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-353 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-352 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-351 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-350 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-349 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-348 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-347 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-346 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-345 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-344 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-343 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-342 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-341 for the 5.8 MacOS 10.0 release)
Changes since the last release (cctools-340 for the 5.7 MacOS X Public Beta release)

Notes Specific to Release 5.7 (MacOS X Public Beta)

New Features

Automatic initialization of dependent libraries

The dynamic linker now calls shared library initialization routines in their dependent order (Radar bug #2441683).

The new function __initialize_Cplusplus() now can be called from a shared library initialization routines to cause the static C++ objects in the library to be initialized. This them allows shared library initialization routines to make use of statically initialized C++ objects. (Radar bug 2441683).

Update to module termination functions

The dynamic linker now supports module termination functions for all types of images (executables, plugins that are not unloaded and shared libraries). This will allow the C++ compiler to use module termination functions for destructors instead of atexit(3) so that a C++ plugin that has a destructor being unloaded does not cause a crash in atexit(3).

Update to support for managing the list of globally exported names

If you are building a dynamic library you nolonger have to do and "ld -r" of all of your object files into one object file. The tool nmedit(1) now can be run on dynamic libraries. Further __private_extern__ symbols can now be used in modules of dynamic libraries that also have definitions of global symbols. (Radar bug 2420307 ).

Changes since the last release (cctools-339 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-338 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-337 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-336 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-335 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-334 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-333 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-332 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-331 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-330 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-329 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-328 for the 5.7 MacOS X Public Beta release)
Changes since the last release (cctools-327 for the 5.6 MacOS X Public Beta release)
Changes since the last release (cctools-326 for the 5.6 MacOS X DP4 release)

Notes Specific to Release 5.6 (MacOS X DP4)

New Features

Support for using shared page table entries on the PowerPC with dynamic libraries

For the current generation of PowerPC chips to be able to share the page table entries among different processes everything mapped from one 256meg boundary to another 256meg boundary must be the same in the different processes. This is has not been possible with MacOS X Mach-O shared libraries as the code and data for each shared library is staticly linked such that the virtual address of the data immediately follows the code. And since the data for each process is different in each process shared page table entries can't be used.

To make it possible for the current PowerPC chips to be able to use shared page table entries a new form of MacOS X Mach-O shared libraries can now be created and used starting with the MacOS X DP4 release. The new form of shared libraries splits the code and data in to two groups. There is one group for the read-only segments generated by the compiler system and one group for the read-write segments.

To create a the new "split" form of shared libraries the new option -segs_read_only_addr <hex_address> is used to specify the preferred virtual address of the read-only segments (where -seg1addr <hex_address> is continued to be used for the existing "flat" non-split shared libraries). The address of the read-write segments is specified with -segs_read_write_addr <hex_address> or defaults to the address of the read-only segments plus 256meg (0x10000000).

Until Radar bug #2443215 is fixed these options can't be specified directly to the compiler driver cc(1). For now the linker options can be used via the -Wl,-linker_option,argument compiler driver option.

When creating a shared library in the split the read-only segments must not contain any relocation entries. So the used of anything but the default -read_only_relocs error is not allowed with the split form of shared libraries.

The kernel starting with the MacOS X DP4 release will reserve two 256meg regions for these split shared libraries to be loaded into every process that uses the dynamic linker. All shared libraries having the split form must be placed in these regions. To make it easier to maintain the preferred virtual addresses of shared libraries an alternate way of specifying their addresses will be used by the projects built by Apple's Build and Integration team for MacOS X. This will involve using a "segment address table" for all dynamic libraries. This segment address table will be built by Apple's Build and Integration team and installed in /AppleInternal/Developer/seg_addr_table. The segment address table will have entries for each shared library containing its install name and its -seg1addr or pair of addresses for its -segs_read_only_addr and -segs_read_write_addr. Then specifying the address of a shared library will be done with the option -seg_addr_table /AppleInternal/Developer/seg_addr_table. Since it may not be possible to get all project building shared libraries to change to using the -seg_addr_table option in a timely manner, this can also be specified via an environment variable. The environment variable LD_SEG_ADDR_TABLE can be set to the file name of the segment address table and if so the static link editor will ignore any -seg1addr, -segs_read_only_addr, -segs_read_write_addr and -seg_addr_table arguments and will then use the addresses from the table.

The local tool seg_addr_table(l) is also provided for used by Apple's Build and Integration team to build and maintain the segment address table. See the man page for more details.

Radar entry #2415906.

Changes since the last release (cctools-325 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-324 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-323 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-322 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-321 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-320 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-319 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-318 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-317 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-316 for the 5.6 MacOS X DP4 release)
Changes since the last release (cctools-315 for the 5.5 MacOS X DP3 release)

 

Notes Specific to Release 5.5 (MacOS X DP3)

New Features

Support removing duplicate debugging information from header files

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

Support the first phase of "coalesced symbols".

I) Goals

The goal of coalesced symbols is to provide the linker support needed for the C++ compiler to solve problems with generating code for the following C++ features:

II) The functionality

A "coalesced symbol" is a true definition of a symbol that may appear one or more times in the compilation units generated by the compiler. This will allow the compiler to provide a better user experience by not forcing the user to tell the compiler exactly where to output the definition of the symbol, which is problematic in implementing some of the above C++ features.

The static link editor will allow multiple definitions of a "coalesced symbol" without any warnings or errors. The static link editor will output only one instance of each "coalesced symbol" using the first instance it encounters in the object files being linked. The static link editor will always output an instance of a "coalesced symbol" if it appears in the object files being linked even if it also appears in the dynamic libraries being referenced.

The dynamic link editor will then do its relocation such that only one instance of each "coalesced symbol" is used throughout the program.

III) The implementation

A Mach-O new section type, "coalesced", has been be added to the compiler tools. A "coalesced symbol" will simply be a symbol defined in a section with the type "coalesced". The assembler has been changed to accept the new section type identifier "coalesced".

For example to create a "coalesced symbol" named _foo as a 4-byte integer initialized to one, the following assembly code could be used:

.section __DATA, __coalesced, coalesced
.globl _foo
_foo: .long 1

An example of a template function created as a "coalesced symbol" could use the following assembly code:

.section __TEXT, __template, coalesced, pure_instructions
.globl _template_func
_template_func:
li r3,1
blr

Once the compiler group establishes conventional sections for various C++ "coalesced symbols" we will add built-in assembler section directives like: .template, .coalesced_data, .rtti_data as equivalents for the above section directives.

A new section type constant, S_COALESCED, has been added to the header file, <mach-o/loader.h> which describes the Mach-O object file format. In the object files created by the assembler "coalesced" section types have this constant in the flags field of the section header.

The static and dynamic linker look at the section type to determine that the symbol is a "coalesced symbol" and allow multiple definitions of "coalesced symbols".

The static link editor effectively divides up a "coalesced section" on the boundaries of the symbols in that section, associating the bytes of the section after each symbol with the preceding symbol. An object file is considered malformed if a "coalesced section" did not have a symbol at the first address of the section.

The symbolic debugging symbol table entries, STABS, for a given coalesced symbol must be preceded by the new begin nsect symbol stab (N_BNSYM) and an end with the new end nsect symbol stab (N_ENSYM). These stabs must be at the start and end of the given coalesced symbol.

IV) The restrictions

In order to allow the dynamic linker to make sure only one instance of of each "coalesced symbol" is used throughout the program, all references to "coalesced symbols" via instructions must be done indirectly through symbol stubs (for calls) or through non-lazy pointers. The static link editor enforces this restriction by checking that there are no direct relocation entries to "coalesced symbol" using section difference relocation entries, and if any are found it will considered the object file malformed. This is must be true even if the coalesced symbol is defined in the same compilation unit where references are also being made.

The assembler and static link editor have also been changed so that if a global symbol is referenced in a "coalesced section" that is defined, an external relocation entry is used instead of a local relocation entry.

Routines generated for C++ static initializers which are initializing a "coalesced symbol" must also be a "coalesced symbol". They do require one code generation change to make it possible that they could be called more than once and only do the initializing the first time. This is required so they dynamic linker does not need to keep track of the initializers for each "coalesced symbol". It will further require the existing implementation in the GNU compiler to change slightly. Currently the GNU compiler generates one initializers function for all C++ static initializers in the compilation unit. This will have to change so that a separate function would be created for initializing a "coalesced symbol".

Lazy binding of symbols vs binding all symbols at launch time

For MacOS X the dynamic linker defaults to lazy binding. That is, symbols are linked into the program as they are needed. For function calls this usually happens when the function is called the first time. For data references this happens before any code that can reference the data is executed. This generally reduces the time it takes to start execution of the program by delaying the binding and initialization of symbols.

With lazy binding, the linking of symbols into the program happens in a distributed fashion as opposed to binding all symbols when the program is launched. A program or plugin may be built with the -bind_at_load option to force all symbols to be bound when the program is launched or when the plugin is loaded.

There can be rare cases where lazy binding and binding at launch can produce different results. These cases can only occur when a program is using more than one library that defines the same symbol, which is not generally a common occurrence. For example a program could be linked against both a debug and non-debug version of the same library. Even in this case, usually both libraries define all the same symbols, so the symbols the program ends up using are those from the first library listed on the program's link line. However if the two libraries do not define the same symbols organized in the same way, that's when these rare cases where lazy binding and binding at launch can produce different results.

To understand these cases one needs to understand what is meant by "how a library's symbols are organized" and how that effects linking. The symbols of a library are organized into modules. Library modules are the object files that were used to build the library and are typically the created from compiling one source file. However the library implementor may combine a number of compiled source files for a library subsystem into a larger object file that is then used to build the library. The library implementor will do this when the interface symbols that make up a subsystem share some private or internal data, such that all the interface symbols for that subsystem must be used together for the subsystem to work correctly. Examples might include a malloc subsystem, a pthreads subsystem, or data base subsystem. These subsystems may have many interface symbols that must be used together as they are sharing data among the interfaces. And the interface symbols would not work correctly if some symbols were used from one implementation and some from another. Rather than just let the program work incorrectly in these cases, when the static or dynamic linker detects these cases they will generate a multiply defined symbol error. Indicating that parts of more than one implementation of a subsystem are trying to be used in the same program.

Now how library modules effects linking is, that if a symbol is needed to resolve an undefined reference, the first library module in the list of libraries that has a definition is used. Then not only is the symbol that resolves the undefined reference used from the library module but all symbols in that same library module are then used.

So when more than one library that defines the same symbol is used, the static and dynamic linkers must select a definition for the symbol to be used from one of the libraries. As stated above, the first library module in the list of libraries that has a definition is used. Then all the symbols from that library module are then used. So which library modules get used by a program is a function of which undefined references must be resolved, the order they are resolved and which symbols are defined in each library module.

For lazy binding and binding at launch the list of undefined references that must be resolved are typically different. For lazy binding this usually is a subset of the undefined symbols that a program uses. So if more than one library is used by the program that defines the same global symbols but are organized into different library modules, it is possible that depending on which undefined references are need to be resolved that different library modules maybe selected. In the case of lazy binding a first subset of the symbols may select a library module from one library and a second subset of symbols may select a library module from a different library. This may lead to multiply defined symbol errors. Or may lead to symbols being used from different implementations of a subsystem.

But in the common case, if no two libraries that are used by a program define the same symbols there is not a difference in lazy binding and binding at launch. Further if there is more than one library that defines the same symbols and the are organized into the same library modules again there is no difference in lazy binding and binding at launch. For MacOS X post PR2, the static link editor, now detects cases where lazy binding and binding at launch could produce different results, and issues a warning. The warning suggests the use of the -bind_at_load option. Also for MacOS X post PR2, the dynamic linker ensures that symbols in a program built with the -bind_at_load option, are the same as the static link editor determined would be used. See Radar bug #2378121.

Changes since the last release (cctools-314 for the 5.5 MacOS X PR3 release)
Changes since the last release (cctools-313 for the 5.5 MacOS X PR3 release)
Changes since the last release (cctools-312 for the 5.5 MacOS X PR3 release)
Changes since the last release (cctools-311 for the 5.5 MacOS X PR3 release)
Changes since the last release (cctools-310 for the 5.5 MacOS X PR3 release)
Changes since the last release (cctools-309 for the 5.5 MacOS X PR3 release)
Changes since the last release (cctools-308 for the 5.5 MacOS X PR3 release)
Changes since the last release (cctools-307 for the 5.5 MacOS X PR3 release)
Changes since the last release (cctools-306 for the 5.4 MacOS X PR2 release)

Notes Specific to Release 5.4 (MacOS X PR2) 

New Features

Dynamic shared libraries now can have a dynamic shared library initialization routine (Radar bug #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). If cc(1) -dynamiclib is used instead of libtool(1), you may need to pass the argument with -Wl,-init, symbol_name until Radar bug #2367569 is fixed. Also gdb(1) will not read the symbols of dynamic shared libraries with library initialization routine due to Radar bug #2367576.

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 Beaker2H3 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 kernel in Beaker2H3 was extended to pass the first argument to exec() to the entry point interface, and having that kernel this feature can be used no matter what argv[0] is.

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.

Changes since the last release (cctools-305 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-304 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-303 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-302 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-301 for the 5.4 MacOS X PR2 release)

Fixed a bug where the intel instruction "setc %al" did not assemble. Radar bug #2374684.

Fixed a bug in the static link editor where the wrong private extern function could be called from a dynamic library. Radar bug #2374465. This resulted in throw() and dynamic_cast() to crash when in a shared library. The Finder was the one having these problems (Radar bugs 2369470 and 2364994).

Changes since the last release (cctools-300 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-299 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-298 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-297 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-296 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-295 for the 5.4 MacOS X PR2 release)
Changes since the last release (cctools-294 for the 5.3 MacOS X PR1 release)

Notes Specific to Release 5.3 (MacOS X PR1)

New Features

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 change 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 is what is 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 (Radar bug #2262020). This has been confirmed by Wilfredo Sanchez the owner of the Apache project. It currently has the following limitations (to be fixed in future releases):

The interface to NSUnLinkModule has change 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 allows unloaded modules with only call sites to undefined functions (direct calls not calls through pointers) to be allowed when unloading and not causing an undefined symbol error. Then if a subsequent module is loaded that defines symbols that were previously undefined, the call sites will then use the new definitions. This is currently only implemented for PowerPC. For intel it prints a message and exits even if the symbol gets redefined. This will be fixed for intel in a future release.

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

The cctools-294 project has an implementation of the FreeBSD dlopen() interfaces. The header file dlfcn.h and the library libdl.a are NOT installed or built by the project by default. This is to avoid automatic configure scripts of projects from using this stuff in release builds before it can be tested by project owners. If an when a future version of cctools has a working set of dlopen() interfaces it will install the header file dlfcn.h and build the library code by default. Most likely the library code will be in included in System framework and not a separate libdl.a. At that time a man page will installed. Currently there is no MacOS X Server version of the man page and the FreeBSD version must be consulted.

There is support for managing the list of globally exported names in cctools that is generally not well known. For managing the list of globally exported names with a list of global symbols that is maintained by the developer the existing tools nmedit(l) and strip(1) can be used. The approach is to build the project normally with full debugging symbols. Then nmedit(1) is run on that with the list of exported symbols and the result is placed in the standard $(SYMROOT). nmedit(1) turns all other global symbols not listed in the file into statics. That resulting file still has all the debugging symbols and can be fully symbolically debugged. Then when the file is copied from the $(SYMROOT) to the $(DSTROOT) in the install process, it is strip(1)'ed with the usual -S (or other options) to remove debugging symbols. This leaves the static symbols as well as the global symbols so that back traces will still have the symbol names. Assuming the list of symbols is in the file save_syms, the example commands would be:

nmedit -s save_syms $(OBJROOT)/hello -o $(SYMROOT)/hello
strip -S $(SYMROOT)/hello -o $(DSTROOT)/hello

If you are building a dynamic library you may also have to do and "ld -r" of all of your object files into one object file. You can also manage the list of globally exported names in your project with nmedit(1) or strip(1).

In the future there will also be compiler support to use the external/internal #pragmas that CFM uses. Today you can use the key word __private_extern__ to get this functionality.

As of cctools-292, the cctools project has been updated to be able to built with the egcs compiler with no warnings from source code of the project (the header files in Beaker1I2 still produce warnings).

The cctools-294 project has been ported and tested on MacOS X using Beaker1L. To build cctools-294 for MacOS X, first the SDK has to be installed on a PowerPC machine with /System/Administration/Installer.app into /Local/Public/MacOSX. Then the commands to build it are:

# ~rc/bin/buildit -release Beaker cctools-293 RC_OS=macos

Only the profileServer is left to be ported. It is currently not built for MacOS X when RC_OS=macos.

Changes since the last release (cctools-293 for the 5.3 MacOS X PR1 release)
Changes since the last release (cctools-292 for the 5.3 MacOS X PR1 release)
Changes since the last release (cctools-291 for the 5.3 MacOS X PR1 release)
Changes since the last release (cctools-290 for the 5.3 MacOS X PR1 release)
Changes since the last release (cctools-289 for the 5.3 MacOS X PR1 release)
Changes since the last release (cctools-288 for the 5.3 MacOS X PR1 release)
Changes since the last release (cctools-287 for the 5.3 MacOS X PR1 release)
Changes since the last release (cctools-286 for the 5.3 MacOS X PR1 release)
Changes since the last release (cctools-285 for the 5.3 MacOS X PR1 release)
Changes made in cctools-285
Changes made in cctools-284
Changes made in cctools-283.1
There are no changes in cctools-283 clone
Changes made in cctools-282

 

Notes Specific to Release 5.2 (Rhapsody CR1)

New Features

The compiler tools now support the 4.4bsd archive extened format 1 for long names (and names with embedded spaces). This is now the default. The option -L to produce archives using the extended format and the option -T to truncate names, as previously supported in the ar(1) command now also apply to ranlib(1) and libtool(1). Radar bug #1670513.

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. Radar bug #2227839.

The VMX opcodes have been added to the Rhapsody PowerPC assembler and are documented in the assembler manual. Radar bug #2237908.

The routine sa_rld_with_symtab() was added for use with the standalone runtime link editor. Radar bug #2231758.

There are no changes in cctools-281.3 clone
Changes made in cctools-281.2
Changes made in cctools-281.1
Changes since the last release (cctools-280 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-279 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-278 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-277 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-276 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-275 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-274 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-273 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-272 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-271 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-270 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-269 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-268 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-267 for the 5.2 Rhapsody CR1 release)
Changes since the last release (cctools-266 for the 5.1 Rhapsody DR2 release)

Documentation 

PowerPC assembler manual (PowerPC Addressing Modes and Assembler Instructions)
See Jeff Mattson (jmattson_ext@next.com) for the latest copy.
Dynamic Shared Libraries User's Guide
The current version of this can be found in (not updated with respect to PowerPC yet):
/Net/seaport/projects/cctools/docs/shlib/user_guide/user_guide.ps
Dynamic Shared Libraries Detailed Design Document
The current version of this can be found in (updated for PowerPC):
/Net/seaport/projects/cctools/docs /shlib/detail_doc/current/detail_doc.ps
Man Pages
Unix manual pages for the cctools release are installed in /usr/share/man. This allows updated manual pages to be used in software by setting the MANPATH environment variable to include one or more paths. For example if the Rhapsody man pages are wanted you might set MANPATH as follows in your .login:
setenv MANPATH /usr/share/man

 

Notes Specific to Release 5.1 (Rhapsody DR2)

New Features

The rld function rld_write_symfile() has been added for use by the kern loader.

Changes since the last release (cctools-265 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-264 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-263 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-262 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-261 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-260 for the 5.1 Rhapsody DR2 release)

Added supporting the PowerPC subtypes 603e, 603ev and 750. Changed NXFindBestFatArch() for PowerPC subtypes to the following: if an exact match is not found the subtype will be picked from the following order: 750, 604e, 604, 603ev, 603e, 603, ALL. Note the 601 is not in the list, it is only picked via an exact match. Changed NXCombineCpuSubtypes() for PowerPC subtypes to the following: combining with the ALL type becomes the other type. Combining anything with 601 becomes 601. All other non exact matches combine to the ALL type. Radar bug #2213821.

Changes since the last release (cctools-259 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-258 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-257 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-256 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-255 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-254 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-253 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-252 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-251 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-250 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-249 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-248 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-247 for the 5.1 Rhapsody DR2 release)
Changes since the last release (cctools-246 for the 5.0 Rhapsody DR1 release)

Documentation 

PowerPC assembler manual (PowerPC Addressing Modes and Assembler Instructions)
See Jeff Mattson (jmattson_ext@next.com) for the latest copy.
Dynamic Shared Libraries User's Guide
The current version of this can be found in (not updated with respect to PowerPC yet):
/Net/seaport/projects/cctools/docs/shlib/user_guide/user_guide.ps
Dynamic Shared Libraries Detailed Design Documen
The current version of this can be found in (updated for PowerPC):
/Net/seaport/projects/cctools/docs /shlib/detail_doc/current/detail_doc.ps
Man Pages
Unix manual pages for the cctools release are installed in /usr/share/man. This allows updated manual pages to be used in software by setting the MANPATH environment variable to include one or more paths. For example if the Rhapsody man pages are wanted you might set MANPATH as follows in your .login:
setenv MANPATH /usr/share/man  

Notes Specific to Release 5.0 (Rhapsody DR1)

New Features

There is only one new feature for the 5.0 release:

The current state of the dynamic shared library port to the PowerPC

As of cctools-246 the all the tools are working or ported. This includes the assembler, the static linker, otool (including it's PowerPC disassembler), the dynamic linker and the various object tools like nm, size, etc. The PowerPC assembler as of the current release is now complete for the Rhapsody Developer release. It now supports all of the PowerPC extended mnemonics and all features of the 603, 603e, 604 and 604e PowerPC architecture.

Current status of the support for the PowerPC

Changes since the last release (cctools-245 for the 5.0 Rhapsody DR1 release)
Changes since the last release (cctools-244 for the 5.0 Rhapsody DR1 release)
Changes since the last release (cctools-242 for the 5.0 Rhapsody DR1 release)
Changes since the last release (cctools-241 for the 5.0 Rhapsody DR1 release)
Changes since the last release (cctools-240 for the 5.0 Rhapsody DR1 release)
Changes since the last release (cctools-239 for the 5.0 Rhapsody DR1 release)
  • Removed the bat[0123][ul] 601 special register names left over from the NRW port. The names with ibat[0123][ul] are to be used.
  • Changed the name of the 601 special register "pid" to "pir" and added the special register name "hid15" also with the number 1023.
  • Removed the special register names rtcd (281), rtci (282) and fpecr (1022) which appear to be left over from the NRW port.
  • Added the special register ear (282) which is optional in the PowerPC.
  • Added the special registers tbl (284) and tbu (285) which were missing.
  • Fixed the clrrdi simplified mnemonics to use rldicr not rldicl which they were using.
  • Added the simplified mnemonic clrlsdi rA,rS,b,n equivalent to rldic rA,rS,n,b-n.
  • Added the multiply low double word (mulld) 64-bit instruction.
  • Added flagging invalid forms of branch conditional instructions where reserved bits of the BO field are not zero when -force_cpusubtype_ALL is not specified.
  • Added flagging all 64-bit compares as invalid forms when -force_cpusubtype_ALL is not specified.
  • Added flagging all 64-bit instructions and optional instructions as invalid forms when -force_cpusubtype_ALL is not specified.
  • Removed the Power forms, ai[.], of the PowerPC instructions addic[.] from the assembler.
  • Removed the non-existant "lmd" instruction from the assembler.
  • Added flagging invalid forms load multiple instructions (lmw, lswi and lswx).
  • Changed the rA parameter of lhax, lfsx, lfdx, ldx, lbzx, lhbrx, lhzx, lwax, lwbrx, stbx, stdcx., stdx, stfdx, stfiwx, stfsx, sthbrx, sthx, stwbrx, stwx, eciwx, ecowx from rA to (rA|0) to match the manual. These are the same as the Radar bug #1653885 for lwzx. The disassembler in otool(1) was also changed to match the manual.
  • Changed the rA parameter of lfdu, lfsu, lhau, ldu, lwzu, stbu, stdu, stfdu, stfsu, sthu and stwu from (rA|0) to rA to match the manual. The disassembler in otool(1) was also changed to match the manual.
  • Added flagging the "branch conditional to count register" (bcctr and bcctrl) that use the "decrement and test CTR" option as invalid forms.
  • Fixed a bug in the static link editor that caused it to exit with an internal error if prebinding was done with objects compiled with PowerPC dynamic code generation.
  • Added the file libstuff/fatals.c to the files installed in the GNU source package as it is needed to build the GNU assembler source.
  • Changed the cctools project so that atom(1) only gets built for OS=nextstep because it uses the encumbered gnu/a.out.h header file.
  • Removed the files gnu/a.out.h and gnu/exec.h from the files that get installed for the GNU source package as they are not needed to build the GNU assembler source and are encumbered with 4.3bsd UNIX.
  • Changes since the last release (cctools-238 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-237 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-236 for the 5.0 Rhapsody DR1 release)

    mttbl rS equivalent to mtspr 284,rS

    Changes since the last release (cctools-235 for the 5.0 Rhapsody DR1 release)
  • Added the following mnemonics to the PowerPC assembler:

    eciwx rD,rA,rB
    ecowx rS,rA,rB
    fres[.] frD,frB
    frsqrte[.] frD,frB
    fsel[.] frD,frA,frC,frB
    fsqrt[.] frD,frB
    fsqrts[.] frD,frB
    stfiwx frs,rA,rB
    tlbsync

  • Added additional forms for the following mnemonics to the PowerPC assembler:\

    mcrfs crfD,crfS

    Allows a crf as the first operand (previously only a number)

    mcrxr crfD

    Allows a crf as the operand (previously only a number)

    mftb rT,TBR

    Allows specifying the value of the timer base register

  • Fixed the 4 parameter forms of cmpli, and cmplwi to take an unsigned immediate not a signed immediate.
  • Fixed the PowerPC clrlslwi macros which were incorrect as:

    clrlslwi[.] ra,rs,b,n equivalent to rlwinm[.] ra,rs,n.b-n,31-b

    corrected to:

    clrlslwi[.] ra,rs,b,n equivalent to rlwinm[.] ra,rs,n.b-n,31-n

  • Changes since the last release (cctools-234 thru cctools-230 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-229 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-228 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-227 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-226 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-225 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-224 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-222 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-221 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-220 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-219 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-218 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-217 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-216 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-215 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-214 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-213 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-212 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-211 for the 5.0 Rhapsody DR1 release)
    Changes since the last release (cctools-209.2 for the 4.2 OpenStep release)

    Documentation 

    PowerPC assembler manual (PowerPC Addressing Modes and Assembler Instructions)
    See Jeff Mattson (jmattson_ext@next.com) for the latest copy.
    Dynamic Shared Libraries User's Guide
    The current version of this can be found in (not updated with respect to PowerPC yet):
    /Network/Servers/seaport/projects/cctools/docs/shlib/user_guide/user_guide.ps
    Dynamic Shared Libraries Detailed Design Document
    The current version of this can be found in (updated for PowerPC):
    /Network/Servers/seaport/projects/cctools/docs/shlib/detail_doc/current/detail_doc.ps
    Man Pages
    Unix manual pages for the cctools release are installed in the standard places. These are updated for for every submission.