Private_CompilerTools.html [plain text]
<HTML>
<!--This file created 8/20/01 3:44 PM by Claris Home Page version 3.0-->
<HEAD>
<TITLE>Private Compiler Tools Release Notes</TITLE>
<META NAME=GENERATOR CONTENT="Claris Home Page 3.0">
<X-CLARIS-WINDOW TOP=72 BOTTOM=847 LEFT=479 RIGHT=1109>
<X-CLARIS-TAGVIEW MODE=minimal>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<P><FONT SIZE="-1">MacOS X 10.1 Release Copyright 2001 by Apple
Computer, Inc. All Rights Reserved.</FONT></P>
<H1>Private MacOS X 10.1 Notes:<BR>
Compiler Tools (cctools-384)</H1>
<P>This file contains release notes for the 5.9 release of the
Compiler Tools for MacOS X 10.1. This file contains information about
the following topics:</P>
<UL>
<LI>The MacOS X Mach-O GNU-based assemblers</LI>
<LI>The MacOS X Mach-O static link editor</LI>
<LI>The MacOS X Mach-O dynamic link editor</LI>
<LI>Mach-O object tools (<B>nm</B>, <B>otool</B>, and so on)</LI>
</UL>
<P> </P>
<H3><FONT SIZE="+2">Notes Specific to Release 5.9 (MacOS X
10.1)</FONT></H3>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<H3><FONT SIZE="+1">Two level namespace</FONT></H3>
<P>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.</P>
<H5><FONT SIZE="+1">Changes since the last release (cctools-383 for
the 5.9 MacOS 10.1 release) </FONT></H5>
<UL>
<LI>Fixed the change to the header file <mach-o/dyld.h> that
added extern "C" ifdef'ed with __cplusplus that had an extra
trailing semicolon after the closing curly brace (Radar bug
#2748160).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-382 for
the 5.9 MacOS 10.1 release) </FONT></H5>
<UL>
<LI>Changied the semantic of NSLookupSymbolInImage() and
NSIsSymbolNameDefinedInImage() to ignore the specified image if it
is not a private image if DYLD_FORCE_FLAT_NAMESPACE is set (Radar
bug #2731330).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-381 for
the 5.9 MacOS 10.1 release) </FONT></H5>
<UL>
<LI>Fixed a bug introduced in cctools-381 that caused libkld to
have an undefined symbol _twolevel_namespace_hints.</LI>
<LI>Picked up the Compiler Tools release notes edits from tech
pubs (Radar bug #2739023).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-380 for
the 5.9 MacOS 10.1 release) </FONT></H5>
<UL>
<LI>Changed the dynamic linker and the
NSCreateObjectFileImageFromFile(3) API to allow for a mechanism
for "future compatibility" when adding new load commands to the
Mach-O object file format (Radar bug #2737644).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-379 for
the 5.9 MacOS 10.1 release) </FONT></H5>
<UL>
<LI>Added the flag <B>-twolevel_namespace_hints</B> to the static
link editor. This specifies to create the output with the
two-level namespace hints table to be used by the dynamic linker.
This is the default except when the <B>-bundle</B> flag is
specified. If this is used when the <B>-bundle</B> flag is
specified the bundle will fail to load on a MacOS X 10.0 system
with a malformed object error. Radar bug #2735266.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-378 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Changed the dynamic linker to not unnecessarily touches link
edit pages for the module table of dynamic libraries when a
dynamic library does not have any module initialization and
termination routines (Radar bug #2732714).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-377 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Changed the header file <mach-o/dyld.h> to have extern
"C" ifdef'ed with __cplusplus (Radar bug #2728016).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-376 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed a problems with the cctools-376 project not building its
cctools_ofiles target due to the changes made for Radar bug
#2716249 (Radar bug #2727607).</LI>
<LI>Fixed a bug in the dynamic linker that caused programs to
crash when DYLD_IMAGE_SUFFIX was used (Radar bug #2724475).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-375 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed the static link editor that caused it to crash when the
-Y flag was used with two-level namespace libraries introduced
with the fix in cctools-375 below for Radar bug #2716249.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-374 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed the PowerPC assembler to protect the short-form macros
which is needed so they do not incorrectly expand under certain
circumstances (Radar bug #2717461).</LI>
<LI>Removed the dependency on libstreams by the assemblers so
nothing in the cctools project depends on</LI>
<LI>Fixed the static link editor to correctly deal with the
semantics of two-level namespace libraries so it won't build
programs that would fail to launch correctly flagging multiply
defined and undefined symbol errors (Radar bug #2716249).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-373 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker that caused programs to get
undefined symbols or crash (in one of dyld's symbol lookup
routines) if the program or one of the libraries had been built
with two-level namespace hints.</LI>
<LI>Fixed a bug in the dynamic linker that caused the Puma5E9
DirectoryService daemon thread count grows unbounded. Radar bug
#2716915</LI>
<LI>Fixed a bug in the optimization to use two-level namespace
prebound libraries in the dynamic linker that caused programs to
crash when using the DYLD_*_PATH enironment variables.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-372 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Changed the static link editor to have -twolevel_namespace as
the default (Radar bug #2717678)</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-371 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Added the optimization to use two-level namespace hints to the
dynamic linker (Radar bug #2558069).</LI>
<LI>Added the -update_overlaps option to the seg_addr_table(1)
tool.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-370 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Added the optimization to use two-level namespace prebound
libraries to the dynamic linker.</LI>
<LI>Changed the static link editor to log the used of the
-bundle_loader argument with the environment variable
XBS_TRACE_BUNDLE_LOADER set (Radar bug #2710229)</LI>
<LI>Changed the dynamic linker to not leak a send port right on
the thread it is doing an operation for (Radar bug #2704241).</LI>
<LI>Fixed a bug in the tool redo_prebinding(1) so it uses "up to
date" not "uptodate" in its error messages (Radar bug
#2711451).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-369.3 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Changed the compiler tools to produce, update, pass through
and print a two-level namespace hints lookup table (Radar bug
#2558069). The dynamic linker does not yet use this table (that
will be done in a subsequent release of cctools).</LI>
<LI>Added the <B>-nomultidefs</B> flag to the the static link
editor. Specifying this flag marks the umbrella being created such
that the dynamic linker is guaranteed that no multiple defintions
of symbols in the umbrella's sub-images will ever exist. This
allows the dynamic linker to always use the two-level namespace
lookup hints even if the timestamps of the sub-images do not
match. This should be used with all Apple umbrellas. This has to
be used with <B>-Wl,-nomultidefs</B> with the compiler driver,
<I>cc</I>(1), until Radar bug #2705158 is fixed.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-369.2 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the tool redo_prebinding(1) that produced an
incorrect error message when run on a binary with debugging
symbols. The incorrect error message reported the file as
malformed because of a bad LIBRARY_ORDINAL in a symbol table
entry.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-369.1 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker when an umbrella library for
a two-level namspace library is loaded after the two-level
namspace library is initally loaded. This would cause refernces
from from sub libraries of the umbrella to symbols in the
two-level library to crash (Radar bug #2706662) .</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-369 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Re-fixed the bug in the dynamic linker API
NSLookupSymbolInImage() where if called from a shared library init
routine it would relocate the library module a second time causing
pointers to have twice their values and the program to crash.</LI>
<LI>Changed the dynamic linker API NSLookupSymbolInImage() to
allow it to take a pointer to the mach header of the executable or
a bundle as well as dynamic libraries.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-368 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the the tool redo_prebinding(1) with undefined
symbol references from two-level images where the definition of
the symbol is in a sub-framework of a flat namespace umbrella
framework would come up undefined.</LI>
<LI>Fixed a bug in the dynamic linker API NSLookupSymbolInImage()
where if called from a shared library init routine it is possible
that it can return a non-NULL NSSymbol but a call to
NSAddressOfSymbol() or other uses of that NSSymbol may not work
(in the case of NSAddressOfSymbol() it returns NULL).</LI>
<LI>Picked up the new rld interfaces kld_load_from_memory &
kld_load_basefile_from_memory (see the rld(3) man page for more
information).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-367 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the static link editor that would cause it to
crash when using -bundle_loader and doing a cross bytesex link
(using -arch i386 while linking on a PowerPC machine for
example).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-366 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Added the -sub_library flag to the static linker and all the
support needed in cctools for it. This is needed to allow
Foundation to lhave libobjc treated as a sub-umbrella (Radar bug
#2697458). For now this must be passed using cc(1) with
-Wl,-sub_library,library_name until and if Radar bug #2699511 is
fixed.</LI>
<LI>Fixed a bug in the redo_prebinding(3) APIs that did not
deallocate a buffer if the open(2) or write(2) fails for it is
output (Radar bug #2691920).</LI>
<LI>Fixed a bug static linker that with -twolevel_namespace it did
not search the sub-umbrella's in the same order as the dynamic
linker.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-365 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker with undefined symbol
references from two-level images where the definition of the
symbol is in a sub-framework of a flat namespace umbrella
framework would come up undefined.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-364 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Added the dynamic linker API's NSAddImage(),
NSLookupSymbolInImage() and NSIsSymbolNameDefinedInImage() for use
in doing two-levelnamespace lookups. For more information see the
NSModule(3) man page (Radar bug #2689833).</LI>
<LI>Fixed a bug in the dynamic linker when
NSLINKMODULE_OPTION_RETURN_ON_ERROR option of the NSLinkModule()
API is used and plugins fail to load it can later cause the
program to crash (Radar bug #2665925).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-363 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Added the -prebind_allow_overlap to the static linker, which
causes it to prebind the output even if the addresses of the
dynamic libraries it uses overlap. The resulting output can then
have redo_prebinding(1) run on it to fix up the prebinding after
the overlapping dynamic libraries have been rebuilt. This option
can also be specified by setting the environment variable
LD_PREBIND_ALLOW_OVERLAP. It is intended for use only in
B&I.</LI>
<LI>Changed NXFindBestFatArch() which had a problem with selecting
the PowerPC cpusubtype when an exact match could not be found. See
Radar bug #2678019 against exec(2) which is the same problem as
this but in the exec code.</LI>
<LI>Changed NXCombineCpuSubtypes() for the PowerPC to select the
highest subtype when there is not an exact match and neither is a
601.</LI>
<LI>Fixed a bug in the dynamic linker when DYLD_LIBRARY_PATH ended
in a ':' that caused it to crash (Radar bug #2676732).</LI>
<LI>Fixed a bug in the dynamic linker when a module from a
prebound dynamic library wasn't originally used by the program was
later dynamically bound and referenced another prebound dynamic
library that also was not originally used that had a C++
constuctor which was not called when the first symbol was
dynamically bound (Radar bug #2650066).</LI>
<LI>Fixed a bug in the dynamic linker that caused prebound dynamic
libraries that had nmedit(1) run on it to not be relocated
correctly and cause the code in them to crash (Radar bug
#2676317).</LI>
<LI>Picked up the change suggested in Radar bug #2686444 which
makes the dynamic linker recurse too much for its algorithm to use
the header dependencices instead of the symbol dependencies when
calling library init routines which was added for Radar bug
#2571628.</LI>
<LI>Picked up a change to the PowerPC assembler adds the 4-arg
option to rlwinm and friends, and uses mask->mb/me (Radar bug
#2684824).</LI>
<LI>Fixed a bug in the assembler when a ".=value" was past the
value of the current location counter and caused the assembler to
crash (Radar bug #2682911).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-362 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Picked up the change suggested in Radar bug #2667248 which is
a small speed up to dyld locking.</LI>
<LI>Picked up the change suggested in Radar bug #2667241 which
added a dyld_mach_thread_self() call to lock.c to improve
preformance by caching the last value of the mach_thread_self()
call against the page truncated stack address making the
call.</LI>
<LI>Fixed a bug in the PowerPC assembler that set the Y bit
inappropriately in bdnzt when no prediction was specified (Radar
bug #2665165).</LI>
<LI>Changed <I>libtool</I>(1) so that if <B>-arch_only</B> is
specified with a specific cpusubtype other than the family
cpusubtype it does not use <B>-force_cpusubtype_ALL</B> and passes
the <B>-arch_only</B> argument to <I>ld</I>(1) as the <B>-arch</B>
flag so that the output is to be tagged with that
cpusubtype..</LI>
<LI>Changed the PowerPC assembler so that vector instructions can
be used when <B>-arch 7400</B> and <B>-arch 7450</B> are specified
without specifying <B>-force_cpusubtype_ALL</B>.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-361 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the redo_prebinding code that did not honor the
sticky bit when creating its output file.</LI>
<LI>Picked up one of the bug fixes to the dynamic linker made in
cctools-361 that was also needed in the redo_prebinding code.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-360 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Made a 4 bug fixes to the dynamic linker for bugs when running
two-level namesapce images. With these fixes the 70 projects that
Sherlock depends on can be built with -twolevel_namespace in
effect and run.</LI>
<LI>The <I>ld</I>(1) and <I>dyld</I>(1) man pages have been
updated with the information about two level name space and the
associated options.</LI>
<LI>Fixed a bug in ld(1) in that caused it to crash when doing a
cross byte sex link with -twolevel_namespace and linking both a
sub-umbrella and its outer umbrella framework.</LI>
<LI>Picked up the fixes for <I>otool</I>(1) -ov from Radar bug
#2660421.</LI>
<LI>The <I>redo_prebinding</I>(3) has been written and is now a
part of cctools-361.</LI>
<LI>Added the slide_to_address parameter to the redo_prebinding(3)
API to be used in the furture to support changing the prefered
address of a dynamic library.</LI>
<LI>Fixed a bug in the <I>redo_prebinding</I>(3) API
needs_redo_prebinding() where after it returned an error, all
subsequent calls return PREBINDING_UNKNOWN.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-359 for
the 5.9 MacOS 10.1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in <I>strip</I>(1) that did not honor the NO_TOC
section attribute when creating archive table of contents (Radar
bug #2663483).</LI>
<LI>Added the <I>redo_prebinding</I>(3) APIs (Radar bug
2604014).</LI>
<LI>Added the <B>-e executable_path</B> argument to
<I>redo_prebinding</I>(1) to allow it to be used with programs and
dynamic libraries that use the "@executable_path" prefix in
install names.</LI>
<LI>Changed the cctoolslib project to no longer build librld and
its varients when RC_RELEASE is not Cheetah (or an earilier build)
as the use of librld was removed earily in the Cheetah build
cycle.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-358 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Added support for two-level namespace (Radar bugs 2372124 and
2415916).</LI>
<LI>Changed the <I>redo_prebinding</I>(1) so that it won't trash
file it is operating on when out of disk space (Radar bug
#2639352).</LI>
<LI>Changed the dynamic linker locking routine to nolonger use an
"extra" sync after a load with reservation which was needed only
for some old 604 processors (Radar bug #2615783).</LI>
<LI>Updated the <I>pagestuff</I>(1) man page as edited by tech
pubs (Radar bug #2582293).</LI>
<LI>Changed the the static linker's, <I>ld</I>(1), overlap
checking when building an executable to not disable prebinding
when the split library's __LINKEDIT segment the executable is
being linked overlap. This can happen when some of the split
libraries linked with are from the $(SYMROOT) and are not
stripped.</LI>
<LI>Changed <I>checksyms</I>(1) to open the default segment
address table if none is specified via a <B>-seg_addr_table</B>
argument (and not try to open the old DylibTable).</LI>
</UL>
<H3><FONT SIZE="+2">Notes Specific to Release 5.8 (MacOS X
10.0)</FONT></H3>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<H3><FONT SIZE="+1">Two level namespace</FONT></H3>
<P>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.</P>
<H5><FONT SIZE="+1">Changes since the last release (cctools-357 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker where a C++ plugin using
templates, stripped with strip(1)'s -s option and then loaded
privately will crash the program loading the plugin. (Radar bug
#2631405).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-356 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Added support for the Vger (7450) cpu subtype to the compiler
tools. Radar bug #2599869.</LI>
<LI>Fixed a bug in the tool seg_addr_table(1) when the -update
option was used that it did not preserve the non-zero addresses in
the table. Instead it changed the non-zero entries to the values
in the libraries were built with. (Radar bug 2575214).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-355 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the tool seg_addr_table(1) where it was not
allowing any padding when laying out split libraries. (Radar bug
2575211).</LI>
<LI>Fixed a bug in the dynamic linker where a multi threaded
program could crash in a library module being linked. (Radar bug
#2584800).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-354 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Changed the include file <mach/vm_task.h> to
<mach/vm_map.h> in two files so that the cctoolslib project
would build on the Cheetah4J8 release. (Radar bug #2579488).</LI>
<LI>Fixed a bug strip(1) where it could complain about not being
able to strip the compiler generated symbols using private extern
coalesced symbols. (Radar bug #2584111).</LI>
<LI>Changed otool(1) to disassemble sections marked with
S_ATTR_SOME_INSTRUCTIONS as some coalesced sections created by the
compiler that are not marked with S_ATTR_PURE_INSTRUCTIONS as they
contain jump tables as well as instructions (Radar bug
#2580311).</LI>
<LI>The assembler has been changed to allow the .section directive
to take mutiple attributes separated with a plus sign '+' (Radar
bug 2580298).</LI>
<LI>Fixed a bug in the implementation of two of
NSLookupAndBindSymbolWithHint () that was causing the symbol
tables to be touched when the symbol was already bound (Radar bug
#2580180).</LI>
<LI>Fixed a bug in the dynamic linker where it would hang the
program when a -run_init_lazily library is used. (Radar bug
#2582778).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-353 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the implementations of two of new lookup with
hint APIs that were added with cctools-353. The two API's that
were fixed were NSLookupAndBindSymbolWithHint () and
_dyld_lookup_and_bind_with_hint() this was causing pbxbuild to
crash in Cheetah4I.</LI>
<LI>Fixed a bug in libtool(1) that caused it to crash when a
-filelist containing 1 file was used.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-352 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>The PowerPC assembler is now installed in
/usr/libexec/gcc/darwin/<B>ppc</B>/as with the other assemblers
installed in /usr/local/libexec/gcc/darwin/<B>arch</B>/as (Radar
bug 2574173).</LI>
<LI>The assembler has been changed to allow the .set directive to
work with expressions of the form a-b and produce an absolute
value for the difference of the symbols even if the symbol are not
yet declared when the .set directive is seen (Radar bug
2573260).</LI>
<LI>The static link editor has been changed to allow compiler to
create position independent (read-only) unwind tables for template
functions that the compiler creates as coalesced symbols (Radar
bug #2564555).</LI>
<LI>Changed dyld's calling of shared library init routines in the
prebound case to not touch the symbol table (Radar bug
2573679).</LI>
<LI>The real implementations for three new lookup with hint APIs
have been added. Previously they were just dummy covers that
called the un hinted APIs. They are NSIsSymbolNameDefinedWithHint
(), NSLookupAndBindSymbolWithHint () and
_dyld_lookup_and_bind_with_hint() defined in <mach-o/dyld.h>
(Radar bug 2571272).</LI>
<LI>The headers files are now installed in /usr/include and
/usr/local/include (Radar bug 2569880).</LI>
<LI>Fixed a bug the static link editor that did not disable
prebinding when symbols in a dynamic library were overridden by
symbols in another dynamic library. Also fixed a bug in the
dynamic linker that incorrectly tried to launch a program where
the same case of symbols in a dynamic library were overridden by
symbols in another dynamic library. This showed up in building a
Cocoa app profiled and the symbols in System framework were being
overidden by the System_profile framework (Radar bug
#2564555).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-351 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Fixed yet another bug in the tool nmedit(1) when used with the
-s file option on a dynamic library hat would cause the module
table to be malformed (specifically the fields nlocalsym and
nextdefsym were likely to have wrong values).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-350 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the tool nmedit(1) when used with the -s file
option on a dynamic library of the opposite byte sex that would
cause the module table to be malformed. Also fixed a bug in the
tool nm(1) that would crash on this type of malformed dynamic
library.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-349 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Added the new environment variable
DYLD_NEW_LOCAL_SHARED_REGION to the dynamic link editor which
causes the split shared libraries to not be loaded in to the
system wide shared region (Radar bug 2567132).</LI>
<LI>Added support for three new lookup with hint APIs. They are
NSIsSymbolNameDefinedWithHint (), NSLookupAndBindSymbolWithHint ()
and _dyld_lookup_and_bind_with_hint() defined in
<mach-o/dyld.h> (Radar bug 2567184).</LI>
<LI>Changed the static link editor to call vm_msync() with the
VM_SYNC_DEACTIVATE option to avoid having the kernel keep all the
pages of the input object files mapped and swapping out all other
tasks (Radar bug #2567196). This seems to fix Radar bug
#2538797.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-348 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Changed the static link editor to use the fcntrl() F_NOCACHE
option to avoid having the kernel cache the pages being written to
the output file (may help fix Radar bug #2538797).</LI>
<LI>Changed the dynamic link editor to use the new kernel api
reset_shared_file(2) to deallocate the memory for a split dynamic
library when it trys to unload it when a plugin fails to load and
the split library was loaded by the plugin (Radar bug 2549068).
Also see the kernel bug in Radar bug #2545459.</LI>
<LI>Made a small optimization in the dynamic linker to inline
bsearch(3) and strcmp(3) which should make launching non-prebound
apps a bit faster (Radar bug 2558068).</LI>
<LI>Added support for the new dyld/gdb interface to the dynamic
linker as documented in <mach-o/dyld_gdb.h> (Radar bug
2559324).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-347 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Clarified the nmedit(1) man page adding a comment about when
both -s and -R are specified (Radar bug 2555491).</LI>
<LI>Changed the tool nmedit(1) to handle symbols listed more than
once in the -s file and not produce a misleading error that the
symbol was not found in file to be edited.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-346 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Added the NSAddLibraryWithSearching api (Radar bug
2535633).</LI>
<LI>Added the _dyld_register_func_for_remove_image api for C++
exception runtime (Radar bug 2553324).</LI>
<LI>Fixed a bug in libtool(1) that did not recognize the
-final_ouput flag correctly (needed for Radar bug 2550094).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-345 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Added logging why a binary was not prebound for B&I when
the environment variable RC_TRACE_PREBINDIND_DISABLED is set
(Radar bug 2550094). Also see compiler driver Radar bug
#2550125.</LI>
<LI>Fixed a bug in the static link editor when a private extern
symbol is referenced from a from coalesced section that generated
an internal ld(1) error when using -bundle. (Radar bug
2548925).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-344 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Changed the static link editor to ignore the
-segs_read_write_addr address it reads from the segment address
table if both the -segs_read_only_addr and -segs_read_write_addr
address are zero use 0x10000000 (256meg) for the
-segs_read_write_addr to construct a valid layout for a split
library. (Radar bug 2544818).</LI>
<LI>Changed the dynamic link editor to not try to deallocate the
memory for a split dynamic library when it trys to unload it when
a plugin fails to load and the split library was loaded by the
plugin (Radar bug 2544696). Also see the kernel bug in Radar bug
#2545459.</LI>
<LI>Fixed a bug in the redo_prebinding(1) tool that caused it to
not work on split dynamic libraries producing dynamic libraries
with the items to be relocated not updated correctly (Radar bug
2544599).</LI>
<LI>Fixed a bug in the redo_prebinding(1) tool that was not
detecting that the dependent libraries of an executable were out
of date with respect to thier prebinding (Radar bug 2544407).</LI>
<LI>Changed the static link editor to allow split dynamic library
__LINKEDIT segments to overlap an not disable prebinding (Radar
bug 2543932).</LI>
<LI>Changed the redo_prebinding(1) tool so that with the -c (check
only) option it will check the installed dynamic library against
the argument of the tool to see the build time stamps match (Radar
bug 2541232).</LI>
<LI>Fixed a bug in the seg_addr_table(1) tool that would cause it
to crash with after a number of messages from malloc are printed
about "Deallocation of a pointer not malloced" (Radar bug
2540744).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-343 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Added the needed support for the static link editor to do with
the tracking and setting the library ordinal for
-twolevel_namespace against the "primary" library. (Radar bug
2538835).</LI>
<LI>The cctoolslib project can now build the kld libraries now
that the kernel framework installes the libsa headers. Radar bug
2538829.</LI>
<LI>Fixed a bug with the -sub_umbrella option in the static link
editor which causes ld(1) to crash when a library built with the
-sub_umbrella option is linked against. (Radar bug 2538825).</LI>
<LI>Fixed a bug with the -allowable_client option in the static
link editor which builds malformed objects for cross bytesex
builds. (Radar bug 2538774).</LI>
<LI>Fixed a bug in the static link editor where it was creating
local relocation entries for global coalesced symbols when the
flag -keep_private_extern was specified (Radar bug 2536788).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-342 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Fixed the inadvernt change to the value of the constant
REFERENCED_DYNAMICALLY in <mach-o/nlist.h> that got changed
as part of Radar bug 2534043.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-341 for
the 5.8 MacOS 10.0 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the change to the static link editor for Radar
bug 2530729 where it also changed the reference table for
non-coalesced symbols which it should not have.</LI>
<LI>Added the needed constants, macros, and comments to the header
files <mach-o/loader.h> and <mach-o/nlist.h> for
supporting two level name space. As well as support for the
-twolevel_namespace, -flat_namespace and -force_flat_namespace
options. (Radar bug 2534043). The compiler driver does not yet
pass these flags (see Radar 2534146) so -Wl,-option can be used
for now.</LI>
<LI>Fixed a bug in the static link editor so that non-lazy
pointers to private extern coalesced symbols work correctly.
(Radar bug 2534011).</LI>
<LI>Added the -allowable_client and -client_name options to the
static link editor to allow other framworks and bundles to link
with a subframework built with -umbrella which are not part of
that umbrella. (Radar bug 2533649). The compiler driver does not
yet pass these flags (see Radar 2534146) so -Wl,-option,argument
can be used for now.</LI>
<LI>Fixed a bug in the tool seg_addr_table(1) where it was
printing a message about an overlapp when it shouldn't. (Radar bug
2531831).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-340 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Fixed a bug in the static link editor when it creates a
dynamic library and discards a private extern coalesced symbol
after already keeping a global one. This produced a dynamic
library that can't be linked against as reference table has the
wrong type of reference (Radar bug 2530729).</LI>
<LI>Added the -sub_umbrella option to the static link editor.
(Radar bug 2530028).</LI>
<LI>Fixed a bug in the tool otool(1) where it was printing a
message about a Stray PPC_RELOC_PAIR relocation entry when it
shouldn't. (Radar bug 2523845).</LI>
<LI>Added the kld(3) interfaces as requested by the driver group.
(Radar bug 2523649).</LI>
<LI>Changed the nmedit(1) and strip(1) commands to allow the file
listing symbol names not to end in a new line. (Radar bug
2520711).</LI>
<LI>Changed the file(1) command to print "CFM binary" instead of
data for CFM binaries. (Radar bug 2511106).</LI>
<LI>Fixed a bug in the dynamic link editor where it would used the
wrong global coalesced symbol if the program overrides a symbol
used by a shared library library init routine in a library that
also defines the shared library init.. (Radar bug 2511358).</LI>
<LI>The dynamic library was changed to allow the environment
variables that effect which libraries a program uses to let root
always use them even for set uid and set gid programs (Radar bug
2497678).</LI>
<LI>The man page for rld was moved from the file rld.3l to rld.3
so man rld will work correctly. (Radar bug 2505760).</LI>
<LI>The sizes of the data structures in the dynamic linker have
been tune to match the Kodiak1G7 Finder. (Radar bug 2504987).</LI>
<LI>The support to allow a shared library routine to be marked to
have its initialization routine run on first use of the library by
the program rather than at program start up when the program is
launched prebound is now extened to module initialization routines
(C++ static initializers). This is done with the shared library is
built via the flag -run_init_lazily. Until Radar bug #2491001 is
fixed this option can't be specified directly to the compiler
driver <I>cc</I>(1). For now the linker option can be used via the
<B>-Wl,</B><I>-linker_option</I><B>,</B><I>argument</I> compiler
driver option. This feature is broken in the Kodiak1G7 kernels,
see Radar bug #2504021. (Radar bug 2502941).</LI>
<LI>Fixed a bug in the static link editor where it generates a
warning about the use of a global coalesced symbol not coming from
the first dynamic library when it shouldn't. (Radar bug
2503703).</LI>
<LI>Fixed a bug in the static link editor where a global coalesced
symbol is repodted as a multply defined symbol when first defined
in a dynamic library then in a static library. (Radar bug
2503694).</LI>
<LI>Fixed a bug in the static link editor when a private extern
coalesced symbol is defined in a dynamic shared library and the
static link editor creates a modlule table entry with the wrong
number of external defined symbols. This results in a malformed
dynamic library. (Radar bug 2503688).</LI>
<LI>Changed the tools nmedit(1) and strip(1) to not change global
coalesced symbols into statics or strip them. (Radar bug
2503670).</LI>
<LI>Fixed a memory leak in the NSCreateObjectFileImageFromFile()
API. (Radar bug 2500014 ).</LI>
</UL>
<H4><FONT SIZE="+2">Notes Specific to Release 5.7 (MacOS X Public
Beta)</FONT></H4>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<H3>Automatic initialization of dependent libraries</H3>
<P>The dynamic linker now calls shared library initialization
routines in their dependent order (Radar bug #2441683).</P>
<P>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).</P>
<H3>Update to module termination functions</H3>
<P>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).</P>
<H3>Update to support for managing the list of globally exported
names</H3>
<P>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 ).</P>
<H5><FONT SIZE="+1">Changes since the last release (cctools-339 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Changed the dynamic link editor so that the debugger interface
does not cause the task being debugged to hang. (Radar bug
2487248).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-338 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Updates the cctools project with the edited release notes from
tech pubs. (Radar bug 2510274).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-337 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Fixed a bug in the assembler that would not set the correct
value for the trailing N_FUN stab which was the difference of a
symbol at the end of the function and the function symbol when the
function was large. (Radar bug 2504182).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-336 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Fixed a bug in the static link editor when a private extern
symbol is referenced from a from coalesced section that generated
an internal ld(1) error. (Radar bug 2497954).</LI>
<LI>The segment address table tool, seg_addr_table(1), was changed
to allocate the read-only region of split libraries starting at
0x70000000 and the read-write regions starting at 0x80000000.
(Radar bug 2496843).</LI>
<LI>Changed the dynamic linker to align the stack it starts using
to 32 bytes where previously it was aligened to 16 bytes. (Radar
bug 2495403).</LI>
<LI>Changed the tool nmedit(1) to make it compatible with an
upcoming compiler change that creates a new an end of function
symbolic table entry. This new entry has an empty name for a N_FUN
stab which nmedit(1) previouly generated an error when
encountered. (Radar bug 2495413).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-335 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Added support for marking coalesced symbols and to not appear
in a static libraries table of contents. This will be used for
RTTI data genetated by the C++ compiler. (Radar bug 2494286).</LI>
<LI>Fixed a bug in the dynamic linker which would crash in
_dyld_image_containing_address if a plugin was unloaded. This
showed up in Kodiak1E5 with
/Developer/Applications/OpenGLInfo.app/Contents/MacOS/OpenGLInfo.
(Radar bug 2493911 also 2496107).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-334 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Fixed a bug resulting in an internal error in the static link
editor when linking objects with private extern coalesced symbols.
(Radar bug 2493452).</LI>
<LI>Fixed a bug in the static link editor when creating relocation
entries for literal pointer sections used by Objective-C for split
libraries. This would cause the dynamic linker to crash the
program when the library was not loaded at its prefered address.
(Radar bug 2493445).</LI>
<LI>Fixed a bug in the dynamic linker with respect to
@executable_path not finding a library sometimes. (Radar bug
2493400).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-333 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Added support to allow a shared library routine to be marked
to have its initialization routine run on first use of the library
by the program rather than at program start up when the program is
launched prebound. This is done with the shared library is built
via the flag -run_init_lazily. Until Radar bug #2491001 is fixed
this option can't be specified directly to the compiler driver
<I>cc</I>(1). For now the linker option can be used via the
<B>-Wl,</B><I>-linker_option</I><B>,</B><I>argument</I> compiler
driver option. (Radar bug 2490396).</LI>
<LI>The verification tool has been changed not to generate an
error message if a library is not found in the segment address
table if specified. Also all checks for conventional path names of
dynamic libraries has been removed. (Radar bug 2490411).</LI>
<LI>The segment address table tool, seg_addr_table(1), was changed
to pack all the split libraries into the first 128meg of a split
256meg region. Also it now checks so that only the first 128meg of
a 256meg split segment is allocated. (Radar bug 2490413).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-332 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Changed the dynamic linker for gratuitous changes to
load_shared_file() in Kodiak1E. (Radar bug 2484973).</LI>
<LI>Fixed a bug in strip(1) and nmedit(1) which produces bad
outputs for fat files with more than one architecture. (Radar bug
2484851).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-331 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker that caused programs to
crash that used used signal() when trying to fully bind the signal
handler which showed up in Kodiak1C4. (Radar bug 2483733 ).</LI>
<LI>Fixed a bug in the tool seg_addr_table(l) when the -update
operation was used where it would sometimes not update the entries
to be updated with the correct address. Also added the
-disablewarnings option. (Radar bug 2482327).</LI>
<LI>The tool nmedit(1), the dynamic and static linker has been
changed to allow nmedit(1) to be run on dynamic libraries. (Radar
bug 2420307).</LI>
<LI>The dynamic linker has the changes need to support the changes
in the load_shared_file() interface. (Radar bug 2480801).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-330 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>The cctools-331 project has the change that was missed for the
Kodiak1C directory layout so that the release notes are installed
in /Developer/Documentation/ReleaseNotes/CompilerTools.html
instead of
/System/Developer/Documentation/ReleaseNotes/CompilerTools.html as
was changed for Kodiak1A.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-329 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>The dynamic linker has a fix for a bug that was introduced
with the code to call shared library initialization routines in
their dependent order for an edge case that caused the program to
crash in dyld. The edge case is when a shared library
initialization routine ends up depending on the executable and
there are undefined symbols (Radar bug 2477856).</LI>
<LI>The dynamic linker now uses the variable _cpu_has_altivec and
the new kernel trap processor_facilities_used() to determine when
to save fp and altivec registers (Radar bug 2477859).</LI>
<LI>The cctools-330 project has the changes for the Kodiak1C
directory layout so that /Library/Frameworks is used instead of
/MacOSX/Library/Framework as was changed for Kodiak1A (Radar bug
#2477862).</LI>
<LI>Fixed an error message in the static linker for the incorrect
usage of the -umbrella flag where -sub_framework was used where
-umbrella should have been used (Radar bug 2477866).</LI>
<LI>Changed the static linker, libtool and the assemblers so they
once again send messages to ProjectBuilder (Radar bug
2473864).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-328 for
the 5.7 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>Fixed a bug in the strings(1) command that caused it not to
read standard input if any command line argument was specified
(Radar bug #2459126).</LI>
<LI>The dynamic linker now calls shared library initialization
routines in their dependent order (Radar bug 2441683).</LI>
<LI>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). This requires the
dylib1.o from the Csu-33 project (Radar bug 2466821).</LI>
<LI>The dynamic linker now supports module termination functions
for all types of images (executables, plugins that are not
unloaded and shared libraries) (Radar bug #2469527). This requires
the crt1.o from the Csu-33 project (Radar bug #2466821).</LI>
<LI>A check has been added to the PowerPC assebler to check the
range of a PPC_RELOC_BR14 and PPC_RELOC_BR24. Previously it
assembled the branch instructions wrong that overflowed without
any error (Radar bug #2469441).</LI>
<LI>Added the new routines NSCreateCoreFileImageFromFile(3) and
_dyld_debug_task_from_core(3) to support getting the information
about the state of the dynamic libraries in a core file (Radar bug
#2155790).</LI>
<LI>Created the man pages NSModule(3) and NSObjectFileImage(3)
(Radar bug #2469604).</LI>
<LI>Fixed a bug in libtool/ranlib that did not deal with zero
length archive members that had long names and used 4.4BSD
extended format #1 and caused ranlib to crash (Radar bug
#2460604).</LI>
<LI>Changed nmedit(1) and strip(1) to allow Macintosh \r's in the
files specified with lists of symbols (Radar bug #2458346).</LI>
<LI>Fixed a few bugs in the seg_addr_table(l) tool. The first was
a problem with not correctly reporting the previous file name that
had an address that matched the table when another library did not
match the table's address. The second was when -upate was used and
a new library like a _profiled version was added with a 0x0
address and there was an existing version with an assigned address
the tool complained abou the new library not having the correct
address (Radar bug #2469876).</LI>
<LI>Changed the seg_addr_table(l) tool to check to make sure it
does not assign any addresses above 0xc0000000 since this address
space is not available on intel in user space (Radar bug
#2418080).</LI>
<LI>Changed the PowerPC assembler to check to make sure that 14
bit branch instructions do not overflow (Radar bug #2469441).</LI>
<LI>Cleaned up the yet to be implemented NSReplaceModule() API,
added enum for other link edit errors and changed the yet to be
implemented NSCreateObjectFileImageFromMemory() API to return
NSObjectFileImageFailure (Radar bug #2469558).</LI>
<LI>Changed the checksyms(l) tool to check to allow debug symbols
for _debug frameworks and libraries (Radar bug #2469760).</LI>
<LI>Changed libtool(1) to pass the -whatsloaded flag on to ld(1)
(Radar bug #2469803).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-327 for
the 5.6 MacOS X Public Beta release)</FONT></H5>
<UL>
<LI>The cctools-328 project has the change to the new directory
layout for /usr/local/lib/system instead of
/AppleInternal/Developer/System.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-326 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>The cctools-327 project has the changes to support the new
directory layout. The old layout can still be built from the
cctools-327 project if RC_RELEASE is Gonzo and the -othercflags
-D__GONZO_BUNSEN_BEAKER__ is defined.</LI>
</UL>
<H3><FONT SIZE="+2">Notes Specific to Release 5.6 (MacOS X
DP4)</FONT></H3>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<H3>Support for using shared page table entries on the PowerPC with
dynamic libraries</H3>
<P>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.</P>
<P>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.</P>
<P>To create a the new "split" form of shared libraries the new
option <B>-segs_read_only_addr</B> <I><hex_address></I> is used
to specify the preferred virtual address of the read-only segments
(where <B>-seg1addr</B> <I><hex_address></I> is continued to be
used for the existing "flat" non-split shared libraries). The address
of the read-write segments is specified with
<B>-segs_read_write_addr</B> <I><hex_address></I> or defaults
to the address of the read-only segments plus 256meg
(0x10000000).</P>
<P>Until Radar bug #2443215 is fixed these options can't be specified
directly to the compiler driver <I>cc</I>(1). For now the linker
options can be used via the
<B>-Wl,</B><I>-linker_option</I><B>,</B><I>argument</I> compiler
driver option.</P>
<P>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 <B>-read_only_relocs error</B> is not allowed with the
split form of shared libraries.</P>
<P>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 <B>-seg1addr</B> or pair of addresses for its
<B>-segs_read_only_addr</B> and <B>-segs_read_write_addr</B>. Then
specifying the address of a shared library will be done with the
option <B>-seg_addr_table</B>
<I>/AppleInternal/Developer/seg_addr_table</I>. Since it may not be
possible to get all project building shared libraries to change to
using the <B>-seg_addr_table</B> option in a timely manner, this can
also be specified via an environment variable. The environment
variable <B>LD_SEG_ADDR_TABLE</B> can be set to the file name of the
segment address table and if so the static link editor will ignore
any <B>-seg1addr</B>, <B>-segs_read_only_addr</B>,
<B>-segs_read_write_addr</B> and <B>-seg_addr_table</B> arguments and
will then use the addresses from the table.</P>
<P>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.</P>
<P>Radar entry #2415906.</P>
<H5><FONT SIZE="+1">Changes since the last release (cctools-325 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>Fixed a bug NSCreateObjectFileImageFromFile(3) where it does
not vm_deallocate(2) the memory for an object file if it is not an
MH_BUNDLE type. Radar bug #2459727.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-324 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the static link editor which caused it to
crash. Most notably when run via libtool with the error
"/usr/bin/libtool: fatal error in ld".</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-323 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>Changed the dynamic link editor to support using just prebound
dynanmic libraries when there are coalesced symbols.</LI>
<LI>Fixed a bug in the static link editor when linking coalesced
symbols that only appear in dynamic libraries getting a mutiply
defined symbol error that shouldn't.</LI>
<LI>Fixed a few bugs in the seg_addr_table (l) tool. The first was
a problem with not correctly stepping over the fixed regions not
to allocate when doing a -relayout or an -update. The second was
with using a -seg_addr_table argument and it failing with a can't
open error.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-322 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>Changed again the cctools and cctoolslib projects to leave
things in /System/Library when built for the Space release train
(changed back from cctools-322). The release notes are put into
/MacOSX/Documentation/Developer/ReleaseNotes instead of
/System/Documentation/Developer/ReleaseNotes for the Space
release. Also the libraries that are part of the System framework
are installed in /AppleInternal/Developer/System instead of
/Local/Developer/System for the Space release. The project
currently relys on RC_RELEASE being set to Space and the macro
__SPACE__ being defined. When this becomes the default for the
Gonzo release train these things will be tweaked to make this
happen by default for the Gonzo release train.</LI>
<LI>Fixed a bug in the tool redo_prebinding(1) which could cause a
shared library initialization routine not to be called. Radar bug
#2450931.</LI>
<LI>Changed the dynamic linker to use VRsave to know which Altivec
registers to save before calling shared library initialization or
module initialization routines. With gcc 2.95 now the default,
VRsave is now correctly set. Radar bug #2450639.</LI>
<LI>The -checkonly option has been added to the seg_addr_table(l)
tool at the request of Apple's Build and Integration team. See the
man page for details.</LI>
<LI>The tool check_dylib(l) has been created for Apple's Build and
Integration team. See the man page for details.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-321 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>Changed the cctools and cctoolslib projects to build and put
things in /MacOSX/System instead of /System/Library when built for
the Space release train. Also the release notes are put into
/Developer/ReleaseNotes instead of
/System/Documentation/Developer/ReleaseNotes. The project
currently relys on RC_RELEASE being set to Space and the macro
__SPACE__ being defined. When this becomes the default for the
Gonzo release train these things will be tweaked to make this
happen by default for the Gonzo release train.</LI>
<LI>Fixed the end(3) man page to correctly reference get_end(3).
Radar bug #2448020.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-320 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>Changed the assembler so the built in section directives
.objc_class_names, .objc_meth_var_types and .objc_meth_var_names
now use the (__TEXT,__cstring) section. Radar bug #2447117.</LI>
<LI>Changed checksyms(l) not to check that objc_unique was run on
the file. Radar bug #2448096.</LI>
<LI>Edited the dyld(1) man page to fix its readablity. Radar bug
#2438996 and #2392392.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-319 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>The static linker now has support for guarding against direct
linking of non-umbrella frameworks via the <B>-umbrella</B>
option. See the ld man page for more details. Radar bug #2443212.
Until Radar bug #2443215 is fixed this option can't be specified
directly to the compiler driver <I>cc</I>(1). For now the linker
option can be used via the
<B>-Wl,</B><I>-linker_option</I><B>,</B><I>argument</I> compiler
driver option.</LI>
<LI>Changed the cctools project to install dyld's images.h and
stuff/bool.h into
/System/Library/Frameworks/System.framework/Versions/B/PrivateHeaders/dyld
. Radar bug #2376135.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-318 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>The static and dynamic linker now supports a new "split" form
of shared libraries to to reduced wired-memory usage (see above in
the new features section). Radar bug #2438996.</LI>
<LI>Changed the checksyms(l) used in the B&I verification
process to not require dynamic libraries have execute bits set.
Also changed checksyms(l) to allow all known MacOS X DP3 dynamic
library install paths as a stop gap until information is provided
by the App Packaging owners as to where are the Apple conventional
install paths.</LI>
<LI>Edited the dyld(1) man page to fix its readablity. Radar bug
#2438996.</LI>
<LI>Changed the cctools project to no longer install the GNU
source as this is covered by the Darwin project.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-317 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>Changed the cctools project to also install librld.a into
/usr/local/lib/ . Radar bug #2436955.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-316 for
the 5.6 MacOS X DP4 release)</FONT></H5>
<UL>
<LI>Changed the cctools project top level Makefile to build both
the cctools and cctoolslib targets when RC_RELEASE is Darwin.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-315 for
the 5.5 MacOS X DP3 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker that did not correctly bind
the modules which define shared library initialization routines
after an unsucessful attempt to launch the program using just
prebound shared libraries. Radar bug #2428317.</LI>
<LI>Fixed a bug in the static link editor that generated an error
mesage of the form "malformed object, illegal reference (reference
from a lazy symbol pointer section ..." when linking an object
that was the result of compiling an empty file with the -pg flag.
Radar bug #2431435.</LI>
</UL>
<P> </P>
<H3><FONT SIZE="+2">Notes Specific to Release 5.5 (MacOS X
DP3)</FONT></H3>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<H3>Support removing duplicate debugging information from header
files</H3>
<P>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.</P>
<H3>Support the first phase of "coalesced symbols".</H3>
<H4>I) Goals</H4>
<P>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:</P>
<UL>
<LI>implicit template instantiation</LI>
<LI>static variables in inline functions</LI>
<LI>RTTI</LI>
</UL>
<H4>II) The functionality</H4>
<P>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.</P>
<P>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.</P>
<P>The dynamic link editor will then do its relocation such that only
one instance of each "coalesced symbol" is used throughout the
program.</P>
<H4>III) The implementation</H4>
<P>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".</P>
<P>For example to create a "coalesced symbol" named _foo as a 4-byte
integer initialized to one, the following assembly code could be
used:</P>
<BLOCKQUOTE>.section __DATA, __coalesced, coalesced<BR>
.globl _foo<BR>
_foo: .long 1</BLOCKQUOTE>
<P>An example of a template function created as a "coalesced symbol"
could use the following assembly code:</P>
<BLOCKQUOTE>.section __TEXT, __template, coalesced,
pure_instructions<BR>
.globl _template_func<BR>
_template_func:<BR>
li r3,1<BR>
blr</BLOCKQUOTE>
<P>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.</P>
<P>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.</P>
<P>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".</P>
<P>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.</P>
<P>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.</P>
<H4>IV) The restrictions</H4>
<P>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.</P>
<P>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.</P>
<P>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".</P>
<H3>Lazy binding of symbols vs binding all symbols at launch
time</H3>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<H5><FONT SIZE="+1">Changes since the last release (cctools-314 for
the 5.5 MacOS X PR3 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker that did not save volatile
floating point or Altivec registers before calling shared library
initialization or module initialization routines. Radar bug
#2424571.</LI>
<LI>Fixed a bug in the dynamic linker that did not fully bind
library initialization routines which had private extern
references. Radar bug #2423809.</LI>
<LI>Removed the references to Rhapsody from the libtool man page.
Radar bug #2399334.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-313 for
the 5.5 MacOS X PR3 release)</FONT></H5>
<UL>
<LI>The environment variable DYLD_ABORT_MULTIPLE_INITS has been
added as a debugging aid. When set it causes the program to abort
when multple library initialization routines are being run which
can happen if code called via a library initialization routine
makes a call to a dyld API. Then under the debugger it is easy to
do a back trace and find the code that is making the call to a
dyld API via code called from a library initialization routine.
Radar bug #2423143.</LI>
<LI>Re-fixed a bug in the dynamic linker that did not fully bind
library initialization routines before calling them. There was a
case with Classic crashing. Radar bug #2413950.</LI>
<LI>New the API _dyld_debug_set_error_func() has been added to the
dyld debug API set to better determine what has happened when a
dyld debug API returns DYLD_FAILURE. Radar bug #2421770.</LI>
<LI>The dynamic linker was changed to send a DYLD_MODULE_REMOVED
and then a DYLD_IMAGE_REMOVED event when the plugin is unloaded.
This will allow the debugger to know the plucin is nolonger
present in the task. Radar bug #2421760.</LI>
<LI>The public release notes have been edited by the Tech Pubs
group for DP3. Radar bug #2420736.</LI>
<LI>The tool nmedit is now installed in /usr/bin instead of
/usr/local/bin so that Project Builder can use it for export
lists. Radar bug #2396595.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-312 for
the 5.5 MacOS X PR3 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker that did not fully bind
library initialization routines before calling them. Radar bug
#2419089.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-311 for
the 5.5 MacOS X PR3 release)</FONT></H5>
<UL>
<LI>Changed the static linker to cleanup the code gen of the
compiler where the compiler generates an indirect call to a
function forward defined. This code gen caused a problem when the
dynmaic linker was trying to fully bind a library initialization
routine because the indirect call in this case does not have an
undefined reference in the object module but rather a definition.
This then caused initialization routines to be interleaved when
this call was lazy bound. Radar bug #2417690.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-310 for
the 5.5 MacOS X PR3 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the static linker that caused gdb to print
variables as <incomplete type>. This can only occur if an
incremental link is done as part of building the image (aka ld
-r). Radar bug #2415697.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-309 for
the 5.5 MacOS X PR3 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the static linker that incorrectly printed a
warning message about symbols used from earilier dynamic libraries
and suggesting the use of -bind_at_load when it shouldn't. Also
fixed one more case where something can be successfully staticly
linked with -bind_at_load and then fails to link with a multiply
defined error from the dynamic linker when executed. Radar bug
#2378121.</LI>
<LI>Fixed a bug in the static linker that did not recognize the
-Sn option. Radar bug #2415456.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-308 for
the 5.5 MacOS X PR3 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker that did not fully bind
library initialization routines before calling them. Radar bug
#2413950.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-307 for
the 5.5 MacOS X PR3 release)</FONT></H5>
<UL>
<LI>Support in the static linker was added to remove duplicate
BINCL/EINCL stab groups. This is enabled with the -Si option to
ld(1) and is the default (see new features above). To get the
static linker to not strip any symbols the new option -Sn can be
used. Radar bug #2410704.</LI>
<LI>Changed <mach-o/dyld.h> so that it does not use "bool"
when compiled with the C++ compiler. Radar bug #2412898.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-306 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Added the first phase of support for "coalesced symbols".
Currently only support for -dynamic code gen for PowerPC has been
tested (intel and static code gen is not yet tested). The support
is complete except for prebinding with coalesced symbols. Because
of that reason use of coalesced symbols should not yet be used in
B&I builds. See new features above. Radar bug #2411273.</LI>
<LI>Changed the references to "Rhapsody" to "MacOS X" on the
assembler man page. Radar bug #2399294.</LI>
<LI>Removed the the references to "Rhapsody" on the ar(5) man page
and the statement that the extended format was not supported as
support for it was added back in the Rhapsody DR2 release. Radar
bug #2399338.</LI>
<LI>Added support for the G4 (7400) cpu subtype to the compiler
tools. Radar bug #2397523.</LI>
<LI>The static and dynamic link editors were changed to fix cases
where lazy binding can result in two different globals functions
being used (or multiply defined errors). In these cases the
program needs to be built with the -bind_at_load flag (or run with
DYLD_BIND_AT_LAUNCH set) and the static link editor now detects
these cases and issues a warning suggesting the use of the
-bind_at_load option and then lists the symbols which are used
from dynamic libraries where there is an earilier dynamic library
with a definition of the symbol. See notes above about "Lazy
binding of symbols vs binding all symbols at launch time". Radar
bug #2378121.</LI>
<LI>Added the dyld environment variable DYLD_IMAGE_SUFFIX which
can be set to a library or framework suffix to be used by the
program. Also included in this change is an optimization that
removes some system calls in the case a library has already been
loaded. of Radar bug #2384450</LI>
<LI>Added printing a line of the form "[Logging for Build
& Integration] Used dynamic library: dylib_name", where
dylib_name is a dynamic library being used in the link. This is
done when the environment variable RC_TRACE_DYLIBS is set. Radar
bug #2389955.</LI>
<LI>Fixed a bug in the assemblers where it would ignore a line
followed by a single '#'. Radar bug #2393418.</LI>
<LI>The tool, nmedit(l), was fixed so that "-arch i386" can be
used as the i386 architecture family type like the other object
file tools. This bug caused nmedit(l) with "-arch i386" not to
work on object files that had the i486 cpusubtype. Radar bug
#2405763.</LI>
<LI>The Intel assembler was changed to assemble the 'fild'
instruction the same as the "filds" and the "fist" instruction the
same as the "fists". Radar bug #2410226.</LI>
<LI>The cctools project was changed to install the external
release notes instead of the Documentation project. Radar bug
#2411118.</LI>
</UL>
<H3><FONT SIZE="+2">Notes Specific to Release 5.4 (MacOS X
PR2)</FONT> </H3>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<P>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 <I>symbol_name</I>"
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, <I>symbol_name </I>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.</P>
<P>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.</P>
<P>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().</P>
<P>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.</P>
<BLOCKQUOTE>extern void NSLinkEditError(<BR>
NSLinkEditErrors *c,<BR>
int *errorNumber,<BR>
const char **fileName,<BR>
const char **errorString);</BLOCKQUOTE>
<P>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.</P>
<H5><FONT SIZE="+1">Changes since the last release (cctools-305 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the dynamic linker where a non-lazy reference
from a dynamic library module that only had private extern symbol
definitions was not getting bound. This showed up in keymgr.o from
libcc_dynamic.a referencing the symbol ___eh_global_dataptr. Radar
bug #2391709.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-304 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Fixed a bug in ld(1) when -U flags to allow undefined symbols
and LD_PREBIND was set it would exit non-zero. Radar bug
#2389026.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-303 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Backed out the fix for Radar bug #2378121 done in cctools-303
as it caused progams like Terminal to launch very slowly. Terminal
is calling signal(2) which causes the executable containing the
signal handler to be fully bound. The fix for Radar bug #2378121
in this case caused a big slow down in the case of fully
binding.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-302 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Fixed a bug where gprof -S crashed when run on the Appkit
trying to produce an order file. Radar bug #2377933.</LI>
<LI>Changed a message printed by checksyms(l) from using "release
control" to using "Build & Integration". Radar bug
#2377929.</LI>
<LI>Fixed a bug in the dynamic linker in a case where lazy binding
can result in two different globals functions being used. Radar
bug #2378121.</LI>
<LI>Picked up the Tech Pubs edited dyld(1) man page. Radar bug
#2366767.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-301 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<P>Fixed a bug where the intel instruction "setc %al" did not
assemble. Radar bug #2374684.</P>
<P>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).</P>
<H5><FONT SIZE="+1">Changes since the last release (cctools-300 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the cctools project that caused System
Framework to come up with an undefined for the symbol
_qsort_load_order_values.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-299 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Dynamic shared libraries now can have a dynamic shared library
initialization routine Radar bug #2367584. See new features
above.</LI>
<LI>The PowerPC instruction "vspltisb v1,-1" assembles wrong.
Radar bug #2366525.</LI>
<LI>There was a typo in arch 3 man page where "pcc" should have
been "ppc". Radar bug #2366781.</LI>
<LI>There was a typo in dyld.1 man page where "effect" should have
been "affect". Radar bug #2366750.</LI>
<LI>Fix a bug where the assembler does not catch the error case of
an unterminated .macro directive. Radar bug #2368659.</LI>
<LI>The was a bug in nmedit(1) when using -R and processing more
than one architecture it printed an error stating "more than one
symbol" for a symbol listed in the -R file appeared in the input
file. Also changed nmedit(l) to strip all arch's when no -arch
flags are specified to match the behavior of strip(1). Radar bug
#2367598.</LI>
<LI>Changed the cctools project when building for Beaker
(RC_OS=macos) to not install its headers into the DSTROOT. Radar
bug #2370826.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-298 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Fixes were made to one of the assembly language interfaces in
the dynamic linker to allow it to be used with CFM vector
libraries. Radar bug #2358962.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-297 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Added support for "@executable_path/" in shared library
install names. See new features above.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-296 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>Fixed a bug introduced in the cctools-296 dyld that caused
Terminal (and potentally any program) to crash. This was fixed as
part of the quick looks for Beaker2F and is fixed in the released
Beaker2F1.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-295 for
the 5.4 MacOS X PR2 release)</FONT></H5>
<UL>
<LI>The NSLinkModule() now can return when an error occurs in
loading a module and the new API NSLinkEditError() allows error
information to be retrieved. See new features above.</LI>
<LI>Fixed a bug in NSAddLibrary() that did not load the dependent
libraries. This showed up when doing an NSAddLibrary() on Carbon
and then trying to look up a symbol in the QuickDraw library that
Carbon was linked with.</LI>
<LI>Added the -v (verification flag) to checksyms(1) to print out
a single line for each type of error checksyms finds. Also added
hacks to checksyms(1) to allow all MacOS X PR1 paths for shared
library install names.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-294 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>The sources have had the Darwin copyrights added to them.</LI>
<LI>A bug fix was made to the new API
_dyld_image_containing_address() that was added for cctools-294.
The routine would generally return the wrong for anything loaded
with NSLinkModule() or any non-prebound shared library. The values
used for checking the address ranges effectively had the value of
the vmslide (the difference from the staticly linked address and
the address loaded) added twice. So if the vmslide were zero, as
in the case with prebound libraries things it would work but tend
to fail otherwise (except for the executable which worked).</LI>
</UL>
<H3><FONT SIZE="+2">Notes Specific to Release 5.3 (MacOS X
PR1)</FONT></H3>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<P>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:</P>
<BLOCKQUOTE>extern NSModule NSLinkModule(<BR>
NSObjectFileImage objectFileImage,<BR>
const char *moduleName,<BR>
enum bool bindNow);</BLOCKQUOTE>
<P>to:</P>
<BLOCKQUOTE>extern NSModule NSLinkModule(<BR>
NSObjectFileImage objectFileImage,<BR>
const char *moduleName,<BR>
unsigned long options);</BLOCKQUOTE>
<P>with the options as follows:</P>
<BLOCKQUOTE>#define NSLINKMODULE_OPTION_NONE 0x0<BR>
#define NSLINKMODULE_OPTION_BINDNOW 0x1<BR>
#define NSLINKMODULE_OPTION_PRIVATE 0x2</BLOCKQUOTE>
<P>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:</P>
<BLOCKQUOTE>extern NSSymbol NSLookupSymbolInModule(<BR>
NSModule module,<BR>
const char *symbolName);</BLOCKQUOTE>
<P>Then to get the address of the returned NSSymbol, the existing
NSAddressOfSymbol() API can be used.</P>
<P>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):</P>
<UL>
<LI>only works for plugins (can only be called on modules that
were returned by NSLinkModule).</LI>
<LI>C++ plugins that have static destructor can't be unloaded. The
program will crash in atexit(3) when the unlinked destructor is
attempted to be called.</LI>
<LI>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.</LI>
<LI>The debugger has not been update to know about unloading and
trying to debug a program that unloads it's plugins may confuse or
crash the debugger.</LI>
</UL>
<P>The interface to NSUnLinkModule has change in a compatible way
from:</P>
<BLOCKQUOTE>extern enum bool NSUnLinkModule(<BR>
NSModule module,<BR>
enum bool keepMemoryMapped);</BLOCKQUOTE>
<P>to:</P>
<BLOCKQUOTE>extern enum bool NSUnLinkModule(<BR>
NSModule module,<BR>
int options);</BLOCKQUOTE>
<P>where the options are:</P>
<BLOCKQUOTE>#define NSUNLINKMODULE_OPTION_NONE 0x0<BR>
#define NSUNLINKMODULE_OPTION_KEEP_MEMORY_MAPPED 0x1<BR>
#define NSUNLINKMODULE_OPTION_RESET_LAZY_REFERENCES 0x2</BLOCKQUOTE>
<P>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.</P>
<P>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:</P>
<BLOCKQUOTE>void my_term(void)<BR>
{<BR>
/* do module termination */<BR>
}<BR>
/* #pragma CALL_ON_UNLOAD my_term */<BR>
#pragma SECTION data ".section __DATA, __mod_term_func,
mod_init_funcs"<BR>
static void (*dummy)(void) = my_term;<BR>
#pragma SECTION data</BLOCKQUOTE>
<P>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.</P>
<P>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:</P>
<BLOCKQUOTE>nmedit -s save_syms $(OBJROOT)/hello -o
$(SYMROOT)/hello<BR>
strip -S $(SYMROOT)/hello -o $(DSTROOT)/hello</BLOCKQUOTE>
<P>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).</P>
<P>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.</P>
<P>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).</P>
<P>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:</P>
<BLOCKQUOTE># ~rc/bin/buildit -release Beaker cctools-293 RC_OS=macos</BLOCKQUOTE>
<P>Only the profileServer is left to be ported. It is currently not
built for MacOS X when RC_OS=macos.</P>
<H5><FONT SIZE="+1">Changes since the last release (cctools-293 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>The cctools-294 version of ld(1) as a fix for a crash that
ocurred when building the CoreGraphicsRIP-30 project for
Beaker1L3.</LI>
<LI>The new API _dyld_image_containing_address() was added. It
takes an address and returns TRUE or FALSE depending on if that
address is in any dyld managed image. Radar bug #2325380.</LI>
<LI>The man page for libtool(1) has been updated. Radar bug
#2324061.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-292 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>The cctools-293 project code has the fixes needed to complile
and use POSIX threads instead of cthreads. This has been tested on
Beaker1I2 compiling with -D_ POSIX_THREADS defined (this is
defined in <unistd.h> for Beaker1J2 but not for Beaker1I2).
Testing could not be done using Beaker1J2 as is too unstable. The
code that tried to use pthreads in cctools-292 will not even
compile when _ POSIX_THREADS is defined.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-291 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>The cctools project code now uses POSIX threads instead of
cthreads.</LI>
<LI>The default segment alignment in the static link editor when
linking a PowerPC target is now 4K instead of 8K. All other target
architectures have not changed and their default segment alignment
remains 8K. Radar bug # 2277625.</LI>
<LI>The cctools project code now compiles with no warnings from
the egcs compiler (header files in Beaker1I2 still produce
warnings).</LI>
<LI>Moved the i386 assembler to /usr/local/libexec/i386/as for
MacOS X builds. The assembler driver /usr/bin/as and the compiler
driver /usr/bin/cc are uneffected and will find the assembler in
either the old or new place.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-290 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>Fixed a bug introduced in the cctools-288 ld(1) when doing an
ld -r with an indirect entry for a private_extern. This problem
would show up when executing a binary with the error from dyld:
<UL>
<LI>dyld: /System/Applications/MailViewer.app/MailViewer
Undefined symbols:<BR>
dyld_lazy_symbol_binding_entry_point</LI>
</UL>
</LI>
<LI>The problem in this case was the Message framework built with
the ld(1) that had the bug. This also has been seen in Carbon
apps, with the problem the Carbon framework.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-289 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the code added to nmedit for the -p option. The
bug caused uses of nmedit without the -p option and with the -s
option to not find any symbols listed in the -s argument.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-288 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>Added the -p option to nmedit(l) which instead of changes
symbols to static changes them to private externs. This option is
allowed by itself without a -s or -R option which then changes all
defined symbols to private extern. This is used to change all the
symbols in libcc_dynamic.a to private extern as the C++ compiler
has never supported the keyword __private_extern__.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-287 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>Fixed nmedit(l) to change the indirect symbol table entries
for global symbols it makes static. This problem showed up in
using nmedit for the work around with the egcs compiler and C++
RTTI common data in a dynamic shared library.</LI>
<LI>Fixed ld(1) when doing an ld -r with an indirect entry for a
private_extern. This problem showed up when building the Message
framework and would get the error from ld: "ld: indirect symbol:_y
can not be a private extern". And it also showed up in building
Carbon when using strip which would produce the error message from
ld: "ld: x.o indirect symbol table entry 0 past the end of the
symbol table".</LI>
<LI>Fixed ld(1) to correctly relocate non-lazy symbol pointers for
non-global symbols. This can occur in one of three ways when a
global symbol is changed to a non-global, via private_extern and
ld -r, via nmedit and via strip.</LI>
<LI>Changed dyld to print on stderr not on stdout for it's
debugging output (Radar bug #2274737).</LI>
<LI>Added passing -whyload through libtool(1) to ld(1).</LI>
<LI>Fixed a bug so that if a PowerPC binary used the
RESET_LAZY_REFERENCES NSUnLinkModule() option, and it was not
linked with crt1.0, bundle1.o or dylib1.o that has the ".long
dyld_stub_binding_helper" fix it won't crash.</LI>
<LI>Changed the message printed when the environment variable
RC_TRACE_ARCHIVES is set from: "RC_TRACE_ARCHIVES archive_name"
to: "[Logging for Build & Integration] Used static
archive: archive_name". Radar bug #2310273.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-286 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>The NSLinkModule() now can create private modules and the new
API NSLookupSymbolInModule() allows symbols to be looked up in a
private module. See new features above.</LI>
<LI>The NSUnLinkModule() API is now implemented with enough
functionality to make Apache work (Radar bug #2262020). See new
features above.</LI>
<LI>The cctools-287 project has an implementation of the FreeBSD
dlopen() interfaces. See new features above.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-285 for
the 5.3 MacOS X PR1 release)</FONT></H5>
<UL>
<LI>Support for module termination functions has been added for
things loaded with NSLinkModule() when NSUnLinkModule() is called.
In this version of cctools NSUnLinkModule() is not implemented
(that will be integrated in a later version). For now to test this
-DTESTING_MOD_TERM needs to be set in RC_CFLAGS.</LI>
<LI>Change the use of the i386 cpp macro to __i386__ and ppc to
__ppc__ so this this version of cctools will compile with the
upcoming release of the egcs compiler.</LI>
</UL>
<H5><FONT SIZE="+1">Changes made in cctools-285</FONT></H5>
<UL>
<LI>Fixed a bug in libtool(1) that was not using NEXT_ROOT when
set to expand -l flags.</LI>
<LI>Added printing a line of the form "RC_TRACE_ARCHIVES
archive_name", where archive_name is a archive being put into the
output of libtool(1) -static or being linked against by ld(1).
This is done when the environment variable RC_TRACE_ARCHIVES is
set. Radar bug #2303376.</LI>
<LI>Made a change to the way the cctools project builds it's
objects for the System framework. It now creates archives in
/Local/Developer/System for libdyld, librld and libmacho. It
creates profile versions with _pg and -static compiled versions
with _static in the filenames. Radar bug #2268413.</LI>
<LI>Removed an incorrect warning in ld(1) that stated
<I>-keep_private_externs</I> must be used with <I>-dynamic</I>.
This would be produced when using ld(1) with <I>-static</I>.</LI>
<LI>Fixed a bug in ld(1) that was producing an incorrect error of
the form "indirect symbol table entry 353 past the end of the
symbol table". This can occured when a file is strip(1)'ed and
global symbols are removed. This was found when the CoreGraphics
framework was stripped removing two globals symbols and then the
resulting framework was linked against.</LI>
<LI>Fixed a bug in the i386 assembler in assembling the cmpxchg
instruction. Previously this assembled using the opcode from the
i486 manual ( 0F A6/r and 0F A7/r ) and was changed to the opcode
in the Pentium manual (0F B0/r and 0F B1/r). The dissassembly in
otool(1) was also changed.</LI>
<LI>Fixed a bug in ranlib(1) (aka libtool) after printing warnings
about with multiple symbols defined different archive members it
crashed with a bus error.</LI>
<LI>Fixed a bug in strip(1) when using the <I>-s filename</I>
option on a dynamic library. This showed when linking against a
CoreGraphics framework, the resulting link would fail with a
malformed object error "ilocalsym field plus nlocalsym field of
module table entry 1 past the end of the symbol table".</LI>
<LI>Changed the #import <sys/types.h> in ranlib.h to
#include <sys/types.h>. Radar bug #2303937.</LI>
<LI>Made cctools 285 build without -DNeXT defined.</LI>
<LI>A fix was made to the dyld debug code that get the thread
suppend count of reset correctly for the thread that has the dyld
lock when the dyld debug thread handles a message.</LI>
<LI>The fixes were made to the dyld debug code made in cctools
283.1 were picked up. Includes Radar bug #2286661.</LI>
<LI>The fixes to moved the text files gprof.flat and gprof.callg
from /usr/lib to /usr/share made in cctools 281.2 were picked
up.</LI>
</UL>
<H5><FONT SIZE="+1">Changes made in cctools-284</FONT></H5>
<UL>
<LI>The fix to ar(1), made in cctools-281.1 (Radar bug #2284290)
was merged in. The changed made to fix the dyld debug code made in
cctools-283.1 are not in cctools-284.</LI>
</UL>
<H5><FONT SIZE="+1">Changes made in cctools-283.1</FONT></H5>
<UL>
<LI>Fixes were made to the dyld debug code for the port to MacOS X
(Mach 3.0) to get it working.</LI>
</UL>
<H5><FONT SIZE="+1">There are no changes in cctools-283
clone</FONT></H5>
<H5><FONT SIZE="+1">Changes made in cctools-282</FONT></H5>
<UL>
<LI>The tools have been ported to MacOS X. The needed code is
#ifdef'ed __MACH30__ which is defined in <mach/mach.h> when
building for MacOS X.</LI>
</UL>
<P> </P>
<H3><FONT SIZE="+2">Notes Specific to Release 5.2 (Rhapsody
CR1)</FONT></H3>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<P>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.</P>
<P>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.</P>
<P>The VMX opcodes have been added to the Rhapsody PowerPC assembler
and are documented in the assembler manual. Radar bug #2237908.</P>
<P>The routine sa_rld_with_symtab() was added for use with the
standalone runtime link editor. Radar bug #2231758.</P>
<H5><FONT SIZE="+1">There are no changes in cctools-281.3
clone</FONT></H5>
<H5><FONT SIZE="+1">Changes made in cctools-281.2</FONT></H5>
<UL>
<LI>Moved text files gprof.flat and gprof.callg from /usr/lib to
/usr/share . gprof/Makefile and gprof/gprof.h were changed. Radar
bug #2287470.</LI>
</UL>
<H5><FONT SIZE="+1">Changes made in cctools-281.1</FONT></H5>
<UL>
<LI>In a stat struct there are three struct timespec's (defined in
sys/time.h). The field name ts_sec was change to tv_sec to match
Posix (Radar bug #2005170). So in for cctools, the use in
ar/archive.c of the field ts_sec was changed to tv_sec in three
places. Radar bug #2284290.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-280 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Changed redo_prebinding to exit with a error code of 3 if the
dependent libraries are out of date. Radar bug #2259447.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-279 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Changed libtool to pass -F and -L flags to objcunique. Radar
bug #2257931.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-278 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>A bug fix was made to the dyld library debug code that fixes a
problem which prevents gdb getting the symbols for dynamic
libraries. Radar bug #2255036.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-277 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>The header file <mach-o/rld.h> was moved to
PrivateHeaders in the System Framework as it uses
<streams/streams.h> in it's API. Radar bug #2249999.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-276 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Changed the handling of unknown i386 and ppc subtypes so that
the routines never fail but return sprintf()'ed strings for the
decriptions. For i386 the string will be of the form "Intel family
X model Y" and for ppc it will be "PowerPC cubsubtype X". Radar
bug #2241690.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-275 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Build fix, the Radar bug #2239280 in strip(1) was using a data
structure after it was free()'ed. The free() call was move after
the last use.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-274 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the static link editor where the module name of
dynamic shared library was set wrong. This happened when creating
a dynamic shared library from an archive library member that had a
long name (using the 4.4bsd archive extened format 1). The module
name dynamic shared library would end up like "#1/20" rather than
its correct name. Radar bug #2239283.</LI>
<LI>Fixed a bug in strip(1) when stripping a dynamic shared
library. This happened when the stripping was removing a symbol
defined in one module and referenced in other modules. The
library's table of contents was not correctly updated to reflect
this symbol was no longer defined. This would then cause the
static link editor to think the library was malformed as a module
was loaded did not define a symbol as expected in the table of
contents. Radar bug #2239280.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-273 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>The VMX opcodes have been added to the Rhapsody PowerPC
assembler. Radar bug #2237908.</LI>
<LI>Fixed a bug that caused NSModuleForSymbol() to return NULL
when called in a module initializer routine on a symbol in that
module. Radar bug #2238301.</LI>
<LI>Removed the -arch i586SX and added the following intel x86
specific subtype archs: pentium, pentpro, pentIIm3 and pentIIm5.
Radar bug #2231830.</LI>
<LI>Fixed a bug in dyld that used the wrong segment's address for
executable's base relocation address. It was using the segment
with the lowest address not the first segment's address. Radar bug
#2237029.</LI>
<LI>Changed the way the static link editor assigns segment address
of segments that were not specified on the command line.
Previously the static link editor often picked overlapping
addresses for these segments and the link would then fail. Now the
static link editor assigns segment address at the next available
address after the first segment that doesn't overlap with other
segments. So if some segments are assigned address the first
segment must also be assigned, which can be done via -seg1addr or
by name with -segaddr. Radar bug #2237029.</LI>
<LI>A missing test was added to the static link editor. This is to
prevent it from producing an executable that is prebound which
would crash when launched and prebinding was disabled. This
happens when too much address space is spanned and the first
segment is more than 24-bits away from a prebound lazy pointer.
This occurred with BlueBox. Radar bug #2237029.</LI>
<LI>Fixed a bug in the dyld debug library code the caused it to
crash (usually the debugger). This would tend to happen on
executables being debugged that did not have it headers linked at
the default address. This occurred with BlueBox. Radar bug
#2236161.</LI>
<LI>Added the <I>-R filename</I> options to strip(1) and
nmedit(l). This specifies a list of specific symbols to be removed
(or changed to static in the case of nmedit(l)). Also changed the
filename syntax to allow white space around symbol names and
comment lines starting with a '#'. Radar bug #2235926.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-272 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Changed dyld so that it does a fflush(3) after doing any
printing with printf(3) so that ProjectBuilder's launcher gets the
ouput of things like DYLD_PRINT_LIBRARIES and it does not get
buffered in the pipe(2)'ed output. Radar bug #2227265. Was
approved for cctools-268 but was never integrated.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-271 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Fixed two bugs in dyld that prevents programs launching
programs with many frameworks that reference many other
frameworks. Radar bug #2230181.</LI>
<LI>The routine sa_rld_with_symtab() was added for use with the
standalone runtime link editor. Radar bug #2231758.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-270 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Build fix, changed libtool(1) -static not to flag -L<I>dir</I>
and -l<I>x</I> flags as warings as they are valid flags with
-static.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-269 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Build fix, corrected the routine get_toc_byte_sex() which did
not have code to deal with the archive extended format #1. This
would cause ld(1) to think the table of contents was malformed if
the first member after the table of contents was in extended
format #1.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-268 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Build fix, backed off change to libtool(1) to treat incorrect
flags as warnings not hard errors.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-267 for
the 5.2 Rhapsody CR1 release)</FONT></H5>
<UL>
<LI>Build fix, removed getmachhead.o from libmacho/dylib.ofileList
.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-266 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>The program checksyms(l) used in the Build and Integration
build verification pass, now checks that projects are prebound and
has no relocation entries in read only sections. Radar bug
#2227469.</LI>
<LI>Changed the profileServer to use bootstrap_register() rather
than bootstrap_check_in() so that it can be started from
/etc/bootstrap.conf. See the man page for details. Radar bug
#2227888.</LI>
<LI>The VMX opcodes have been added back in to the assembler.
Radar bug #2227999.</LI>
<LI>Changed all of the compiler tools to support the 4.4bsd
archive extened format 1. The tools ranlib(1) and libtool(1) now
take the -L option to produce archives using the extended format
and the -T option to truncate names. The default is -L. Radar bug
#1670513.</LI>
<LI>The error message printed in dyld for the case when the path
name of a dynamic library turns out to be a path name of a
directory has been changed. Previously it just printed can't
map_fd the path name. It now prints the file name is not a regular
file. Radar bug #2227477.</LI>
<LI>The processing of the environment variables for dyld paths has
been changed to ignore paths with no characters in them. This led
to confusion when the directory layout was changed to have a
directory named /System and then the System framework would be
searched as /System if a path with no characters in it was in
DYLD_LIBRARY_PATH. Radar bug #2227589.</LI>
<LI>Fixed a bug in nm(1) with the -o option on a dynamic shared
library that did not print the colon ':' between the library
module name and symbol name. Radar bug #2227852.</LI>
</UL>
<H3><FONT SIZE="+2">Documentation</FONT> </H3>
<H5><FONT SIZE="+1">PowerPC assembler manual (PowerPC Addressing
Modes and Assembler Instructions)</FONT></H5>
<BLOCKQUOTE>See Jeff Mattson (jmattson_ext@next.com) for the latest
copy.</BLOCKQUOTE>
<H5><FONT SIZE="+1">Dynamic Shared Libraries User's Guide</FONT></H5>
<BLOCKQUOTE>The current version of this can be found in <B>(not
updated with respect to PowerPC yet)</B>:
<BLOCKQUOTE>/Net/seaport/projects/cctools/docs/shlib/user_guide/user_guide.ps</BLOCKQUOTE></BLOCKQUOTE>
<H5><FONT SIZE="+1">Dynamic Shared Libraries Detailed Design
Document</FONT></H5>
<BLOCKQUOTE>The current version of this can be found in <B>(updated
for PowerPC)</B>:
<BLOCKQUOTE>/Net/seaport/projects/cctools/docs
/shlib/detail_doc/current/detail_doc.ps</BLOCKQUOTE></BLOCKQUOTE>
<H5><FONT SIZE="+1">Man Pages</FONT></H5>
<BLOCKQUOTE>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:
<BLOCKQUOTE>setenv MANPATH /usr/share/man</BLOCKQUOTE></BLOCKQUOTE>
<P> </P>
<H3><FONT SIZE="+2">Notes Specific to Release 5.1 (Rhapsody
DR2)</FONT></H3>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<P>The rld function rld_write_symfile() has been added for use by the
kern loader.</P>
<H5><FONT SIZE="+1">Changes since the last release (cctools-265 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the change of the default headerpad in ld(1) to
be the sizeof two section structures because objcunique(1) now can
add 2 section headers.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-264 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Changed the default headerpad in ld(1) to be the sizeof two
section structures because objcunique(1) now can add 2 section
headers.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-263 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Added a definition of getenv() in the dyld code that always
returns NULL so the reference to_dyld_lookup_and_bind() is not
pulled in by the libc_dynamic code.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-262 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>The VMX opcodes have been removed. Radar bug #2219166.</LI>
<LI>A bug was fixed in the code that starts the dyld debug thread
that effected executables who's load commands were larger than 4k
(like ProjectBuilder). Radar bug #2218925.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-261 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>The use of the profil(2) system call has been updated to
reflect the fix in the kernel for the bucket incremented in
profileServer(1) and in dyld. Radar bug #2215979.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-260 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<P>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.</P>
<UL>
<LI>Added the dcba PowerPC optional instruction to the assembler
and otool.</LI>
<LI>Added the special register names for the PowerPC 750
processor:Radar bug #2212878
<P><TABLE BORDER=0 WIDTH="48%" HEIGHT=210>
<TR>
<TD>
<P>Special register name</P>
</TD>
<TD>
<P>Number</P>
</TD>
</TR>
<TR>
<TD>
<P>ummcr0</P>
</TD>
<TD>
<P>936</P>
</TD>
</TR>
<TR>
<TD HEIGHT=8>
<P>upmc1</P>
</TD>
<TD HEIGHT=8>
<P>937</P>
</TD>
</TR>
<TR>
<TD>
<P>upmc2</P>
</TD>
<TD>
<P>938</P>
</TD>
</TR>
<TR>
<TD>
<P>usia</P>
</TD>
<TD>
<P>939</P>
</TD>
</TR>
<TR>
<TD>
<P>ummcr1</P>
</TD>
<TD>
<P>940</P>
</TD>
</TR>
<TR>
<TD>
<P>upmc3</P>
</TD>
<TD>
<P>941</P>
</TD>
</TR>
<TR>
<TD>
<P>upmc4</P>
</TD>
<TD>
<P>942</P>
</TD>
</TR>
<TR>
<TD>
<P>l2cr</P>
</TD>
<TD>
<P>1017</P>
</TD>
</TR>
<TR>
<TD>
<P>ictc</P>
</TD>
<TD>
<P>1019</P>
</TD>
</TR>
<TR>
<TD HEIGHT=12>
<P>thrm1</P>
</TD>
<TD HEIGHT=12>
<P>1020</P>
</TD>
</TR>
<TR>
<TD>
<P>thrm2</P>
</TD>
<TD>
<P>1021</P>
</TD>
</TR>
<TR>
<TD>
<P>thrm3</P>
</TD>
<TD>
<P>1022</P>
</TD>
</TR>
</TABLE>
</P></LI>
<LI>Assembling PowerPC VMX instructions now requires the
-force_cpusubtype_ALL flag. And code that uses them must dynamicly
check to see if VMX is supported on the processor before using VMX
instructions. Radar bug #2213821.</LI>
<LI>Change the PowerPC instructions tlbld and tlbli to marked as
OPTIONAL rather than 603 specific. This leaves the only
instructions specific for a PowerPC cpu being 601 instructions.
Radar bug #2213821.</LI>
<LI>Moved the assemblers into /usr/libexec and /usr/local/libexec.
Radar bug #2213838.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-259 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Added the path /Local/Library/Frameworks to checksyms(l) as a
conventional path Frameworks can be found in. Also corrected
"it's" to "its" in error messages.</LI>
<LI>Added -c to all the install(1) commands in all the
Makefiles.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-258 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Changed cctools to not use /usr/local/bin/install where it
needed the -sS option but rather call strip -S and create a
temporary file and install the temporary file.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-257 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Changed checksyms(l) to once again treat /usr/lib/java as a
conventional path libraries can be found in. This path got changed
to /System/Library/Frameworks/JavaVM.framework/Libraries where
that path should have been just added.</LI>
<LI>Fixed dylib shared pc sampling. Radar bug #2004555.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-256 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Changed checksyms(l) to treat
/System/Library/Frameworks/JavaVM.framework/Libraries as a
conventional path libraries can be found in.</LI>
<LI>Changed the default address of dyld to 0x41100000.</LI>
<LI>Changed cctools to use /usr/local/bin/install where it needs
the -sS option.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-255 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Changed checksyms(l) to treat /usr/lib/java as a conventional
path libraries can be found in. Radar bug #2005914.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-254 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>The VMX opcodes have been added. Radar bug 2004760.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-253 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Fixed a bug in ld(1) that prevented the Objective-C runtime
optimization using _dyld_bind_objc_module() from working. The bug
was in the routine that swaps the module table of a dynamic
library.</LI>
<LI>Added the rld function rld_write_symfile() for use by the kern
loader.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-252 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Updated the cctools project for the new directory layout for
Premier (changing the directories with the word Next in them). See
the updated man pages for specific details.</LI>
<LI>Added the -b option to checksyms(l) to check dynamic binaries
for relocation entries in read-only sections, make sure they are
prebound and have had objcunique run on them. This is not yet the
default.</LI>
<LI>Delt with a bug in the 4.4bsd ar(1) which produced bad
archives when the uid (or gid) field overflowed or underflowed.
Radar bug #2000486.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-251 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the disassembly output of otool(1) for ppc bl
instructions that was not printing any address or symbol. Also
added printing out a comment for branch targets to symbol stubs
including the name of the symbol the stub is for.</LI>
<LI>Changed the ppc dissassembly in otool(1) of "addis rX,0,immed"
to "lis rX,immed" and "addi rX,0,immed" to "li rX,immed".</LI>
<LI>Updated the dyld(1) man page to include the default fall back
paths.</LI>
<LI>Removed the -arch m98k which was the same as -arch ppc.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-250 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Corrected the bug fix in ld(1) when doing prebound builds in
Slick build environment with $NEXT_ROOT set. The change also
effected Titan builds because RC builds do have $NEXT_ROOT set (to
nothing).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-249 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>The man pages now get installed into /usr/share/man directly
out of the cctools project. The man pages had some small updates
cleaning up some things. arch(3) was added to the cctools set and
updated. The also now have Apple Computer, Inc. on them instead of
NeXT.</LI>
<LI>Fixed a bug in as(1) where it would not take the cpu specific
arch types -arch ppc604 or -arch ppc604e. Also changed the
assembler to print out the cctools version as the Apple version
instead of the NeXT version.</LI>
<LI>Changed the ppc locking code in dyld to allow it to be stepped
over by single step profiling tools using the step to branch mode
in that code.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-248 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Changed libtool(1) and redo_prebinding(1) look for objcunique
in /usr/bin rather than in /bin.</LI>
<LI>Added support for the ppc architecture to
redo_prebinding(1).</LI>
<LI>Fixed a bug in ld(1) when prebinding and segments in the
output file overlap dependent libraries. In this case the output
gets marked as prebound even though a message is printed that says
it was disabled. This would cause redo_prebinding(1) to fail on it
because of overlapping segments.</LI>
<LI>Fixed a bug in ld(1) when prebinding with -i options. The
indirect symbols being defined with -i options were being turned
into prebound undefined symbols. Then after the binary was
strip(1)'ed redo_prebinding(1) would fail on it because of
undefined symbols.</LI>
<LI>Fixed a bug in ld(1) when doing prebound builds in Slick build
envorinment with $NEXT_ROOT set. It was recording the dynamic
libraries name with $NEXT_ROOT prepened to it in LC_PREBOUND_DYLIB
load commands.</LI>
<LI>Fixed a bug where the ouput of nm(1) -n was not sorted
correctly.</LI>
<LI>Fixed a potentinal bug in dyld if a very long symbol name was
to be printed as part of an error message it could have crashed
the program.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-247 for
the 5.1 Rhapsody DR2 release)</FONT></H5>
<UL>
<LI>Changed the gmon.out format gprof(1) understands to be in sync
with the 4.4bsd format. The header file <mach-o/gmon.h> is
no longer installed and the 4.4bsd file in <sys/gmon.h> with
Rhapsody updates is now used.</LI>
<LI>Fixed a bug that would cause programs to segfault if dyld had
to relocate itself because the executable overlapped with dyld's
prefered address.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-246 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>The project source tree has been converted to build natively
on Rhapsody.</LI>
<LI>The binaries are now installed in the correct places for a
4.4BSD system. There are nolonger any symbolic links to other
locations. Radar bugs #1673496, #1680747 and #1682569.</LI>
<LI>The command ar(1) was changed to have the -T options on by
default. This causes archive member names to be truncated and does
not use the extend format for long names which the compiler tools
does not yet understand. The new option -L causes the extend
format to be used. The hope is the compiler tools will understand
the extened format for the Rhapsody Unified release. Radar bug
#1670513.</LI>
<LI>Removed the comment allowing the moduleName parameter of
NSLinkModule() in <mach-o/dyld.h> to be NULL. Radar bug
#1670835.</LI>
</UL>
<H3><FONT SIZE="+2">Documentation</FONT> </H3>
<H5><FONT SIZE="+1">PowerPC assembler manual (PowerPC Addressing
Modes and Assembler Instructions)</FONT></H5>
<BLOCKQUOTE>See Jeff Mattson (jmattson_ext@next.com) for the latest
copy.</BLOCKQUOTE>
<H5><FONT SIZE="+1">Dynamic Shared Libraries User's Guide</FONT></H5>
<BLOCKQUOTE>The current version of this can be found in <B>(not
updated with respect to PowerPC yet)</B>:
<BLOCKQUOTE>/Net/seaport/projects/cctools/docs/shlib/user_guide/user_guide.ps</BLOCKQUOTE></BLOCKQUOTE>
<H5><FONT SIZE="+1">Dynamic Shared Libraries Detailed Design
Documen</FONT></H5>
<BLOCKQUOTE>The current version of this can be found in <B>(updated
for PowerPC)</B>:
<BLOCKQUOTE>/Net/seaport/projects/cctools/docs
/shlib/detail_doc/current/detail_doc.ps</BLOCKQUOTE></BLOCKQUOTE>
<H5><FONT SIZE="+1">Man Pages</FONT></H5>
<BLOCKQUOTE>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:
<BLOCKQUOTE>setenv MANPATH /usr/share/man </BLOCKQUOTE></BLOCKQUOTE>
<H3><FONT SIZE="+2">Notes Specific to Release 5.0 (Rhapsody
DR1)</FONT></H3>
<H3><FONT SIZE="+1">New Features</FONT></H3>
<P>There is only one new feature for the 5.0 release:</P>
<UL>
<LI>The tools now use -arch ppc for the PowerPC architecture . The
tools have been brought up the 603, 603e, 604 and 604e PowerPC
from the 601. Support for dynamic shared libraries has been
added.</LI>
</UL>
<H3>The current state of the dynamic shared library port to the
PowerPC</H3>
<BLOCKQUOTE>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.</BLOCKQUOTE>
<H3>Current status of the support for the PowerPC</H3>
<H5><FONT SIZE="+1">Changes since the last release (cctools-245 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the static link editor for PPC_RELOC_JBSR
relocation types. The other_part field was being tuncating to the
low16 bits.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-244 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>The symbolic links made in /usr/bin for the commands as, ld,
strip, strings, nm and size for which the binaries are in /bin
were corrected to use a relative path. Radar bug #1672088.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-242 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Symbolic links were made in /usr/bin for the commands as, ld,
strip, strings, nm and size for which the binaries are in /bin.
Radar bug #1672088.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-241 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Removed the builtin macro clrlsdi which was a typo for the
correct macro clrlsldi.</LI>
<LI>Removed the following builtin macros left over from the NRW
port: mtrtcd, mfrtcd, mtrtci, mfrtci, mtbatu, mfbatu, mtbatl and
mfbatl.</LI>
<LI>Changed the PowerPC instruction "eciwx" to be marked as
optional so to require -force_cpusubtype_ALL when used.</LI>
<LI>Removed the non-existant "stmd", "mtpmr" and "mfpmr"
instructions from the PowerPC assembler.</LI>
<LI>Fixed the following extended mnemonics to the PowerPC
assembler:
<P><TABLE BORDER=0 WIDTH="49%">
<TR>
<TD>
<P>mtrtcu Rx</P>
</TD>
<TD>
<P>equivalent to</P>
</TD>
<TD>
<P>mtspr 20,Rx</P>
</TD>
</TR>
<TR>
<TD>
<P>mtrtcl Rx</P>
</TD>
<TD>
<P>equivalent to</P>
</TD>
<TD>
<P>mtspr 21,Rx</P>
</TD>
</TR>
</TABLE>
</P>
<P>Note these are 601 specific and the special register numbers
moving to (20,21) the Real Time Clock are diffierent from moving
from (4,5) the same registers.</P></LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-240 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Fixed a bug that caused bundles to not load on the PowerPC
604e as there was no table entry in the ArchInfoTable.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-239 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Changed the PowerPC assembler to nolonger support the
mull[o][.] and mulwd[.] instructions
produced by the NRW compiler.</LI>
<LI>Added the special register names:
<P><TABLE BORDER=0 WIDTH="61%" HEIGHT=260>
<TR>
<TD WIDTH=215>
<P>Special register name</P>
</TD>
<TD WIDTH=168>
<P>Number</P>
</TD>
<TD WIDTH=157>
<P>Processor</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>mmcr0</P>
</TD>
<TD WIDTH=168>
<P>952</P>
</TD>
<TD WIDTH=157>
<P>604 and 604e</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>pmc1</P>
</TD>
<TD WIDTH=168>
<P>953</P>
</TD>
<TD WIDTH=157>
<P>604 and 604e</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>pmc2</P>
</TD>
<TD WIDTH=168>
<P>954</P>
</TD>
<TD WIDTH=157>
<P>604 and 604e</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>sia</P>
</TD>
<TD WIDTH=168>
<P>955</P>
</TD>
<TD WIDTH=157>
<P>604 and 604e</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>mmcr1</P>
</TD>
<TD WIDTH=168>
<P>956</P>
</TD>
<TD WIDTH=157>
<P>604e</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>pmc3</P>
</TD>
<TD WIDTH=168>
<P>957</P>
</TD>
<TD WIDTH=157>
<P>604e</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>pmc4</P>
</TD>
<TD WIDTH=168>
<P>958</P>
</TD>
<TD WIDTH=157>
<P>604e</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>sda</P>
</TD>
<TD WIDTH=168>
<P>959</P>
</TD>
<TD WIDTH=157>
<P>604 and 604e</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>dmiss</P>
</TD>
<TD WIDTH=168>
<P>976</P>
</TD>
<TD WIDTH=157>
<P>603</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>dcmp</P>
</TD>
<TD WIDTH=168>
<P>977</P>
</TD>
<TD WIDTH=157>
<P>603</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>hash1</P>
</TD>
<TD WIDTH=168>
<P>978</P>
</TD>
<TD WIDTH=157>
<P>603</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>hash2</P>
</TD>
<TD WIDTH=168>
<P>979</P>
</TD>
<TD WIDTH=157>
<P>603</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>imiss</P>
</TD>
<TD WIDTH=168>
<P>980</P>
</TD>
<TD WIDTH=157>
<P>603</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>icmp</P>
</TD>
<TD WIDTH=168>
<P>981</P>
</TD>
<TD WIDTH=157>
<P>603</P>
</TD>
</TR>
<TR>
<TD WIDTH=215>
<P>rpa</P>
</TD>
<TD WIDTH=168>
<P>982</P>
</TD>
<TD WIDTH=157>
<P>603</P>
</TD>
</TR>
</TABLE>
</P></LI>
</UL>
<DIR>
<LI>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.</LI>
<LI>Changed the name of the 601 special register "pid" to "pir"
and added the special register name "hid15" also with the number
1023.</LI>
<LI>Removed the special register names rtcd (281), rtci (282) and
fpecr (1022) which appear to be left over from the NRW port.</LI>
<LI>Added the special register ear (282) which is optional in the
PowerPC.</LI>
<LI>Added the special registers tbl (284) and tbu (285) which were
missing.</LI>
<LI>Fixed the clrrdi simplified mnemonics to use rldicr not rldicl
which they were using.</LI>
<LI>Added the simplified mnemonic clrlsdi rA,rS,b,n equivalent to
rldic rA,rS,n,b-n.</LI>
<LI>Added the multiply low double word (mulld) 64-bit
instruction.</LI>
<LI>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.</LI>
<LI>Added flagging all 64-bit compares as invalid forms when
-force_cpusubtype_ALL is not specified.</LI>
<LI>Added flagging all 64-bit instructions and optional
instructions as invalid forms when -force_cpusubtype_ALL is not
specified.</LI>
<LI>Removed the Power forms, ai[.], of the PowerPC
instructions addic[.] from the assembler.</LI>
<LI>Removed the non-existant "lmd" instruction from the
assembler.</LI>
<LI>Added flagging invalid forms load multiple instructions (lmw,
lswi and lswx).</LI>
<LI>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.</LI>
<LI>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.</LI>
<LI>Added flagging the "branch conditional to count register"
(bcctr and bcctrl) that use the "decrement and test CTR" option as
invalid forms.</LI>
<LI>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.</LI>
<LI>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.</LI>
<LI>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.</LI>
<LI>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.</LI>
</DIR>
<H5><FONT SIZE="+1">Changes since the last release (cctools-238 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Fixed a bug that caused bundles to not load on the
PowerPC.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-237 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Fixed a build problem where the file /etc/magic should have
been installed in /private/etc/magic.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-236 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Changed the PowerPC immediate shifted instructions (addis and
lis) to not check the sign of the immediate, but just to check for
out of 16 bit range (signed or unsigned).</LI>
<LI>Fixed the following extended mnemonic for the PowerPC
assembler that was wrong in cctools-235:
<P><TABLE BORDER=0 WIDTH="69%" HEIGHT=20>
<TR>
<TD>
<P>crmove crbT,crbA</P>
</TD>
<TD>
<P>equivalent to</P>
</TD>
<TD>
<P>cror crbT,crbA,crbA</P>
</TD>
</TR>
</TABLE>
</P></LI>
<LI>It was was crxor which it should not have been.</LI>
<LI>Added forms of PowerPC instructions: cmpd, cmpdi, cmpld,
cmpldi, cmpw, cmpwi, cmplw and cmplwi that take a number as their
first parameter (previously they only took a cr register).</LI>
<LI>Added forms of PowerPC instructions "tw 31,0,0" and "ori
0,0,0" toallow the zeros to be encoded where registers are
required.</LI>
<LI>Added the following extended mnemonic to the PowerPC
assembler:</LI>
</UL>
<P>mttbl rS equivalent to mtspr 284,rS</P>
<UL>
<LI>Fixed the PowerPC opcode of "mttbu rS" "Move to time base
upper" to be equivalent to "mtspr 285,rS".</LI>
<LI>Removed the PowerPC instruction mttb "Move to time base".</LI>
<LI>Fixed a bug in the PowerPC instruction "lwzx rD,rA,rB" where
rA should have been (rA|0). Radar bug #1653885.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-235 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Added the PowerPC instruction jbsr pseudo instruction for use
with kernel relocatables. This has the following form:
<P>jbsr _foo,L1<BR>
...<BR>
L1: lis r12,hi16(_foo) ; long branch stub<BR>
ori r12,r12,lo16(_foo)<BR>
mtctr r12<BR>
bctr</P></LI>
<LI>The jbsr pseudo instruction assembles to a bl instruction
targeted at L1. It also generates a PPC_RELOC_JBSR relocation
entry for the symbol _foo. Then when the linker creates a
non-relocatable output file it will change the target of the bl
instruction to _foo if the bl instruction's displacement will
reach. Else it will leave the bl instruction targeted at L1.
<I>otool</I>(1) understands how to disassemble these pseudo
instructions.</LI>
<LI>Fixed a bug in both the static and the dynamic link editors
where it was not correctly checking for relocation overflow for
PPC_RELOC_BR24 relocation types (used with bl instructions). The
checking was off by the high bit as the displacement is
signed.</LI>
<LI>The cctools project has been unencumbered (for Grail,
RC_OS=teflon). The programs ar(1) and file(1) are now ported
OpenBSD versions. They should work the same but beware they are
completely different sources.</LI>
<LI>Added the following extended mnemonics to the PowerPC
assembler:
<P> <TABLE BORDER=0 WIDTH="74%">
<TR>
<TD WIDTH=134>
<P>mtrtcu Rx</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>mtspr rtcu,Rx</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>mtrtcl Rx</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>mtspr rtcl,Rx</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>mtmq Rx</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>mtspr mq,Rx</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>mfrtcu Rx</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>mfspr Rx,rtcu</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>mfrtcl Rx</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>mfspr Rx,rtcl</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>mfmq Rx</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>mfspr Rx,mq</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>mfspr Rx,mq</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>bcctr BO,BI</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>bctrl BO,BI</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>bcctrl BO,BI</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>crmove crbT,crbA</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>crxor crbT,crbA,crbA</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>crnot crbT,crbA</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>crnor crbT,crbA,crbA</P>
</TD>
</TR>
<TR>
<TD WIDTH=134 HEIGHT=10>
<P>mfear rT</P>
</TD>
<TD WIDTH=118 HEIGHT=10>
<P>equivalent to</P>
</TD>
<TD HEIGHT=10>
<P>mfspr rT,282</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>mtear rS</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>mtspr 282,rS</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>mtfs[.] frB</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>mtfsf[.] 0xff,frB</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>la rT,d(rA)</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>addi rT,rA,d</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>cmp crT,rA,rB</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>cmp crT,0,rA,rB</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>cmp num,rA,rB</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>cmp num,0,rA,rB</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>cmpi crT,rA,s16</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>cmpi crT,0,rA,s16</P>
</TD>
</TR>
<TR>
<TD WIDTH=134 HEIGHT=12>
<P>cmpi num,rA,s16</P>
</TD>
<TD WIDTH=118 HEIGHT=12>
<P>equivalent to</P>
</TD>
<TD HEIGHT=12>
<P>cmpi num,0,rA,s16</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>cmpl crT,rA,rB</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>cmpl crT,0,rA,rB</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>cmpl num,rA,rB</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>cmpl num,0,rA,rB</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>cmpli crT,rA,s16</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>cmpli crT,0,rA,u16</P>
</TD>
</TR>
<TR>
<TD WIDTH=134>
<P>cmpli num,rA,s16</P>
</TD>
<TD WIDTH=118>
<P>equivalent to</P>
</TD>
<TD>
<P>cmpli num,0,rA,u16</P>
</TD>
</TR>
</TABLE>
</P></LI>
</UL>
<DIR>
<LI>Added the following mnemonics to the PowerPC assembler:
<P>eciwx rD,rA,rB<BR>
ecowx rS,rA,rB<BR>
fres[.] frD,frB<BR>
frsqrte[.] frD,frB<BR>
fsel[.] frD,frA,frC,frB<BR>
fsqrt[.] frD,frB<BR>
fsqrts[.] frD,frB<BR>
stfiwx frs,rA,rB<BR>
tlbsync</P></LI>
<LI>Added additional forms for the following mnemonics to the
PowerPC assembler:\
<P><TABLE BORDER=0>
<TR>
<TD WIDTH=86>
<P>mcrfs crfD,crfS</P>
</TD>
<TD>
<P>Allows a crf as the first operand (previously only a
number)</P>
</TD>
</TR>
<TR>
<TD WIDTH=86>
<P>mcrxr crfD</P>
</TD>
<TD>
<P>Allows a crf as the operand (previously only a
number)</P>
</TD>
</TR>
<TR>
<TD WIDTH=86>
<P>mftb rT,TBR</P>
</TD>
<TD>
<P>Allows specifying the value of the timer base
register</P>
</TD>
</TR>
</TABLE>
</P></LI>
<LI>Fixed the 4 parameter forms of cmpli, and cmplwi to take an
unsigned immediate not a signed immediate.</LI>
<LI>Fixed the PowerPC clrlslwi macros which were incorrect as:
<P>clrlslwi[.] ra,rs,b,n equivalent to rlwinm[.]
ra,rs,n.b-n,31-b</P>
<P>corrected to:</P>
<P>clrlslwi[.] ra,rs,b,n equivalent to rlwinm[.]
ra,rs,n.b-n,31-n</P></LI>
</DIR>
<H5><FONT SIZE="+1">Changes since the last release (cctools-234 thru
cctools-230 for the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>The only changes were to fix build problems relating to new
System Framework & Kernel header files and the switch to the
-dynamic compiler for PowerPC.</LI>
<LI>Removed the changed the static link editor to ignore -seg1addr
(also known as -image_base) for dynamic libraries greater than
0x4000000 for PowerPC. This was only needed to allow static code
gen to be used with Frameworks.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-229 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Added ppc604e to the arch table for a specific architecture as
this is returned on some Macs.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-228 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>The changed the assembler in cctools-228 was wrong. It
resulted in producing bad code when compiling -static (triggered
by the change to compiler in cc-752). The change has been fixed in
the cctools-229 assembler.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-227 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Changed the assembler to allow section difference relocations
with the -static flag. This fixes using the cc-752 and getting the
"Can't emit reloc ..." error message from the assembler.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-226 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Added the PowerPC mnemonics ai and ai. the assembler which are
archaic forms of addic[.] as the compiler currently
generates them in some cases.</LI>
<LI>Fixed otool -c for use with PowerPC core files.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-225 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Added ppc604 to the arch table for a specific architecture as
this is what the Kernel is returning on the Power Mac 8500. This
was causing code that supported loading bundles to fail (this is
library code in System framework, thus a new System framework
needs to be built and used to see this fix).</LI>
<LI>Fixed a bug in the dynamic link editor where it was not
correctly calculating the immediate of a HA16 reloc by checking
the 0x8000 bit of the other half. This was causing address to be
off by 0x10000.</LI>
<LI>Fixed a bug in the dynamic link editor when the $HOME
environment variable was not set. (the case for the single user
prompt on PowerPC). This was causing bus errors when a dynamic
library was not found.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-224 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the static link editor where the __PAGEZERO
segment was not being created for PowerPC (left over from NRW when
executables started at high addresses and the kernel was at
zero).</LI>
<LI>Changed the static link editor to ignore -seg1addr (also known
as -image_base) for dynamic libraries greater than 0x4000000 for
PowerPC. This will allow static code gen to be used with
Frameworks.</LI>
<LI>Changes since the last release (cctools-223 for the 5.0
Rhapsody release)</LI>
<LI>Changed the source of cctools-224 to define NO_INDR_LIBC if
__TEFLON__ is defined so it will build with SDK2 which is not
using <I>indr</I>(l). This will allow cctools-224 to built for the
Grail RC target.</LI>
<LI>Fixed a bug in the static link editor when defining common
symbols when a common section exists in the input .o files which
has an alignment less than the alignment needed for the common
symbols being defined by the link editor did not get aligned
correctly.</LI>
<LI>Fixed <I>libtool</I>(1) running on Teflon so it doesn't always
report "internal link edit command failed". The link actually
worked but the checking of the return code for Teflon was
wrong.</LI>
<LI>Fixed <I>as</I>(1) running on Teflon so it doesn't always exit
non-zero when it runs the target assembler (/lib/arch/as). The
assembly actually worked but the checking of the return code for
Teflon was wrong.</LI>
<LI>The other thread states for PowerPC are now printed by otool
(useful for core files).</LI>
<LI>Added the PowerPC simplified mnemonics crset, crclr and mtcr
to the assembler.</LI>
<LI>Added the include file <mach-o/ranlib.h> to the cctools
project from <bsd/ranlib.h> and changed <I>off_t</I> type to
<I>unsigned long</I> because <I>off_t</I> on Teflon is 64 bits
which would break compatibility with existing libraries.</LI>
<LI>Added the header files <mach-o/sparc/swap.h>and
<mach-o/ppc/swap.h> which get installed in the System
Framework to be shipped. This and the added library code allows
swapping of thread states.</LI>
<LI>Added the header files <mach-o/i860/swap.h>and
<mach-o/m88k/swap.h> which get installed locally and not
shipped. The code was not added to the System Framework.</LI>
<LI>Changed the cctools package to install
<mach-o/ppc/reloc.h> with the exported headers. And to
install <mach-o/hppa/reloc.h> with the local headers.</LI>
<LI>Changed of the ppc subtypes to match the kernel. Only the 601
and 603 types are currently used by the assembler. The types
currently in use are as follows:
<UL>
<LI>/*<BR>
* PowerPC subtypes<BR>
*/<BR>
#define CPU_SUBTYPE_POWERPC_ALL ((cpu_subtype_t) 0)<BR>
#define CPU_SUBTYPE_POWERPC_601 ((cpu_subtype_t) 1)<BR>
#define CPU_SUBTYPE_POWERPC_602 ((cpu_subtype_t) 2)<BR>
#define CPU_SUBTYPE_POWERPC_603 ((cpu_subtype_t) 3)<BR>
#define CPU_SUBTYPE_POWERPC_603e ((cpu_subtype_t) 4)<BR>
#define CPU_SUBTYPE_POWERPC_603ev ((cpu_subtype_t) 5)<BR>
#define CPU_SUBTYPE_POWERPC_604 ((cpu_subtype_t) 6)<BR>
#define CPU_SUBTYPE_POWERPC_604e ((cpu_subtype_t) 7)<BR>
#define CPU_SUBTYPE_POWERPC_620 ((cpu_subtype_t) 8)<BR>
#define CPU_SUBTYPE_POWERPC_740 ((cpu_subtype_t) 9)</LI>
</UL>
</LI>
<LI>The -arch flags for the 601 and 603 are -arch ppc601 and -arch
ppc603. Others will be defined as needed.</LI>
<LI>Updated the NXFindBestFatArch(3) and NXCombineCpuSubtypes(3)
to include PowerPC guessing at how to combine the PowerPC subtypes
(someone in the OS group should look at this).</LI>
<LI>Updated the ArchInfoTable to include PowerPC and removed mips
and vax which gets returned with NXGetAllArchInfos(3).</LI>
<LI>Updated <mach-o/swap.h> and library code with all the
things for dynamic shared libraries that never made it into the
System Framework code.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-222 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Fixed changes to allow cctools-223 to build for 4.2mach as
well as PowerPC & Intel with Teflon SDK2.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-221 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Added the -stack_addr and -stack_size options to <I>ld</I>(1).
Note the kernel support for these has not yet been added. So the
flags should only be used for bringing up the support in the
kernel at this time. See the <I>ld</I>(1) man page for details on
these flags.</LI>
<LI>Fixed a bug in the link editor <I>ld</I>(1) for PowerPC HA16
relocation types when bit 15 was set in the other half of the
immediate stored in the relocation entry. This resulted in bad
code. This bug was found when bringing up driverkit and is needed
for anyone doing development on driverkit for PowerPC.</LI>
<LI>Fixed a bug in the link editor <I>ld</I>(1) where it generated
an error message for the lazy symbol pointer section in crt1.o for
PowerPC which it shouldn't have. This bug was found bring up
-dynamic code gen for PowerPC and is needed for anyone using
-dynamic code gen for PowerPC.</LI>
<LI>Incorporated many changes to allow cctools-222 to build for
PowerPC & Intel with Teflon SDK2.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-220 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>The thread status for the PowerPC has changed to match the
kernel. This makes all previous executables incompatible. The old
<I>otool</I>(1) will no longer work on PowerPC executables because
of this change. All executables should be relinked.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-219 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the link editor <I>ld</I>(1)where $NEXT_ROOT
did not get prefixed to depenendent dynamic libraries.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-218 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Added searching fallback paths when dynamic libraries can't be
found. The two paths are in the environment variables
DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH. If
these are not set they default to
$(HOME)/Library/Frameworks:/LocalLibrary/Frameworks:/NextLibrary/Frameworks
and $(HOME)/lib:/usr/local/lib:/lib:/usr/lib (bug #69135).</LI>
<LI>Changed the static linker to pad pure instruction sections of
i386 outputs with nop's (bug #77806).</LI>
<LI>Added .section_align <I>align_value</I> to be allowed in
section order files. This causes the symbol following it to be
aligned on a 2^<I>align_value</I> byte boundary (bug #77807).</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-217 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Changed the cctools project to build with gnumake.</LI>
<LI>Updated the locking code and the cache management code in the
dynamic linker for the PowerPC with suggestions from the ppc
bringup team.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-216 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Ported the dynamic linker to PowerPC.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-215 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Changed the standard symbol stubs for the PowerPC to take
advantage of the super scaler nature of the 603 and 604. See the
updated Dynamic Shared Libraries Detailed Design Document for the
details.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-214 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Made the cctools-215 project build (except for linking dyld
and otool) under the Teflon SDK.</LI>
<LI>Fixed the PowerPC assembler to use the correct opcodes for
mftb and mftbu and updated otool's disassembly.</LI>
<LI>Added the support in the static link editor to understand
thePowerPC position-independent relocation entries (section
difference). This allows PowerPC dynamic shared libraries and
executables that use them to be built (Note as stated above there
is not yet a compiler that supports -dynamic for -arch ppc, and
there is no dynamic linker yet for PowerPC).</LI>
<LI>Added the support in the PowerPC assembler for the standard
symbol stubs.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-213 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Added the support in the PowerPC assembler for
position-independent relocation entries (section difference). As
well as support in otool for printing them and dissassembling with
them.</LI>
<LI>Updated the Detailed Design Document with the first cut at the
code generation for -dynamic for the PowerPC. This is just a first
pass to allow getting the assember and otool in place so that the
compiler work can start.</LI>
<LI>Fixed a bug in the PowerPC assembler where it treated the
comment character ';' (semicolon) as a statement separator.</LI>
<LI>Fixed the PowerPC assembler to allow -arch m98k if passed to
it.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-212 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>The header files for mach-o subdirectory and the library files
were added to the cctools project taken from the libc_macho
project.</LI>
<LI>Fixed the typo in the <I>ld</I>(1) warning message for bug
#77070.</LI>
<LI>Fixed a bug in <I>ld</I>(1) that was causing prebinding not to
happen if a private extern had the same name as a global function
in a dependent library (this can occur because -lcc_dynamic is
being linked in).</LI>
<LI>Fixed the PowerPC's assembler manual for compare instructions
to have a 0 not a 1 for the 32-bit version not the 64-bit version.
For example cmp 0,1,RA,RB was changed to cmp 0,0,RA,RB.</LI>
<LI>Changed <I>libtool</I>(1) to ignore the -pg flag.</LI>
<LI>Added the not rA,rT and not. rA,rT instructions.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-211 for
the 5.0 Rhapsody DR1 release)</FONT></H5>
<UL>
<LI>Fixed a bug in the link editor <I>ld</I>(1)where $NEXT_ROOT
did not prefix standard framework paths. Also fixed -Z to not use
standard framework paths.</LI>
<LI>Changed the following instructions to the correct PowerPC
mnemonics:
<P><TABLE BORDER=0 WIDTH="62%">
<TR>
<TD>
<P>NRW compiler mnemonic</P>
</TD>
<TD>
<P>PowerPC mnemonic</P>
</TD>
</TR>
<TR>
<TD>
<P>tlbiex</P>
</TD>
<TD>
<P>tlbie</P>
</TD>
</TR>
<TR>
<TD>
<P>slbiex</P>
</TD>
<TD>
<P>slbie</P>
</TD>
</TR>
</TABLE>
</P></LI>
<LI>Also corrected the opcodes for slbie and slbia
instructions.</LI>
<LI>The bug in the assembler that causes it exits with a zero
status and create an output file if it can't open the input file
has been fixed.</LI>
<LI>The .flag_reg <I>num</I> and .noflag_reg <I>num</I> ppc
directives were added to the assembler to allow warnings to be
generated for specific register uses.</LI>
<LI>The -no_ppc601 flag and the .no_ppc601 directive were added to
the assembler to warn of 601 uses.</LI>
<LI>The 603 instructions tlbld rB and tlbli rB were added to the
assembler.</LI>
<LI>The missing 601 instruction clcs rD,rA was added to the
assembler.</LI>
<LI>Use of instructions specific to the 601 and 603 now cause the
assembler to mark the resulting object file with the specific
cpusubtype. Note the assembler is currently not complete with
respect to instructions for the specfic cpusubtypes. All of the
ppc subtypes have been added to cctools-212's version of
<mach/machine.h> but only the 601 and 603 types are
currently used. The types are as follows:
<UL>
<LI>/*<BR>
* PowerPC subtypes<BR>
*/<BR>
#define CPU_SUBTYPE_POWERPC_ALL ((cpu_subtype_t) 0)<BR>
#define CPU_SUBTYPE_POWERPC_601 ((cpu_subtype_t) 1)<BR>
#define CPU_SUBTYPE_POWERPC_601v ((cpu_subtype_t) 2)<BR>
#define CPU_SUBTYPE_POWERPC_602 ((cpu_subtype_t) 3)<BR>
#define CPU_SUBTYPE_POWERPC_603 ((cpu_subtype_t) 4)<BR>
#define CPU_SUBTYPE_POWERPC_603e ((cpu_subtype_t) 5)<BR>
#define CPU_SUBTYPE_POWERPC_603ev ((cpu_subtype_t) 6)<BR>
#define CPU_SUBTYPE_POWERPC_604 ((cpu_subtype_t) 7)<BR>
#define CPU_SUBTYPE_POWERPC_604e ((cpu_subtype_t) 8)<BR>
#define CPU_SUBTYPE_POWERPC_620 ((cpu_subtype_t) 9)<BR>
#define CPU_SUBTYPE_POWERPC_X704 ((cpu_subtype_t) 10)<BR>
#define CPU_SUBTYPE_POWERPC_603q ((cpu_subtype_t) 11)</LI>
</UL>
</LI>
<LI>The -arch flags for the 601 and 603 are -arch ppc601 and -arch
ppc603. Others will be defined as needed.</LI>
<LI>Changes since the last release (cctools-210 for the 5.0
Rhapsody release)</LI>
<LI>The project sources were changed so that the lib_ofiles target
could be built for teflon in the Grail release control
target.</LI>
</UL>
<H5><FONT SIZE="+1">Changes since the last release (cctools-209.2 for
the 4.2 OpenStep release)</FONT></H5>
<UL>
<LI>Changed the PowerPC assembler to treat $ the same as . (dot)
for the current pc.</LI>
<LI>Changed the treatment of stswi and lswi instruction's third
parameter so that it allows the value 32 in the assembly language
and is treated as if it were 0.</LI>
<LI>Changed the following instructions to the correct PowerPC
mnemonics:
<P><TABLE BORDER=0 WIDTH="46%">
<TR>
<TD WIDTH=139>
<P>NRW compiler mnemonic</P>
</TD>
<TD>
<P>PowerPC mnemonic</P>
</TD>
</TR>
<TR>
<TD WIDTH=139>
<P>mull</P>
</TD>
<TD>
<P>mullw</P>
</TD>
</TR>
<TR>
<TD WIDTH=139>
<P>mull.</P>
</TD>
<TD>
<P>mullw.</P>
</TD>
</TR>
<TR>
<TD WIDTH=139>
<P>mullo</P>
</TD>
<TD>
<P>mullwo</P>
</TD>
</TR>
<TR>
<TD WIDTH=139>
<P>mullo.</P>
</TD>
<TD>
<P>mullwo.</P>
</TD>
</TR>
<TR>
<TD WIDTH=139>
<P>mulwd</P>
</TD>
<TD>
<P>mulhw</P>
</TD>
</TR>
<TR>
<TD WIDTH=139>
<P>mulwd.</P>
</TD>
<TD>
<P>mulhw.</P>
</TD>
</TR>
</TABLE>
</P></LI>
<LI>The NRW compiler mnemonics will continue to work as long as
the NRW compiler is in use. Assembly code should be converted to
use the correct mnemonics. The disassembly of otool -tV uses the
correct PowerPC mnemonics.</LI>
<LI>Fixed the mr instruction (it was ori rA,rS,0 not or rA,rS,rS
as it should have been). Also added the mr. instruction.</LI>
<LI>Changed the lis instruction to treat it's immediate as
unsigned causing it not to flag the instructions like lis
r1,0x8000. This is now consistant with addis r1,0,0x8000.</LI>
<LI>The tools now use -arch ppc for the PowerPC architecture
(previously they used -arch m98k, which still works but is no
longer supported). </LI>
</UL>
<H3><FONT SIZE="+2">Documentation</FONT> </H3>
<H5><FONT SIZE="+1">PowerPC assembler manual (PowerPC Addressing
Modes and Assembler Instructions)</FONT></H5>
<BLOCKQUOTE>See Jeff Mattson (jmattson_ext@next.com) for the latest
copy.</BLOCKQUOTE>
<H5><FONT SIZE="+1">Dynamic Shared Libraries User's Guide</FONT></H5>
<BLOCKQUOTE>The current version of this can be found in <B>(not
updated with respect to PowerPC yet)</B>:
<BLOCKQUOTE>/Network/Servers/seaport/projects/cctools/docs/shlib/user_guide/user_guide.ps</BLOCKQUOTE></BLOCKQUOTE>
<H5><FONT SIZE="+1">Dynamic Shared Libraries Detailed Design
Document</FONT></H5>
<BLOCKQUOTE>The current version of this can be found in <B>(updated
for PowerPC)</B>:
<BLOCKQUOTE>/Network/Servers/seaport/projects/cctools/docs/shlib/detail_doc/current/detail_doc.ps</BLOCKQUOTE></BLOCKQUOTE>
<H5><FONT SIZE="+1">Man Pages</FONT></H5>
<BLOCKQUOTE>Unix manual pages for the cctools release are installed
in the standard places. These are updated for for every
submission.</BLOCKQUOTE>
</BODY>
</HTML>