GCC Notes
---------

New in this release:

  * Compiler support for instruction scheduling.

    Essentially the compiler will try to rearrange the order of
    instructions (where it is safe to do so), in order to reduce or
    remove any delays because of the latencies of instructions.  This
    feature is enabled by default when optimization is enabled.  If
    necessary it can be disabled via the "-fno-schedule-insns" and
    "-fno-schedule-insns2" switches.

  * Support for the AM34 processor.

    There is a new compiler switch: "-mam34".  The only real difference
    between this switch and the "-mam33-2" switch is in the scheduling
    of instructions, although there is also a pre-defined
    pre-processor symbol difference.  With "-mam34" the symbol
    __AM34__ is defined and the symbol __AM33__ is defined with a
    value of 4, whereas with "-mam33-2" the __AM34__ symbol is not
    defined and the __AM33__ symbol is defined with a value of 2.

  * Support for LIW instructions.

    The compiler will now attempt to combine two small instructions
    into one Long Instruction Word where possible.  It will also
    attempt to use the SETLB, Lcc and FLcc instructions to control
    very tight loops.  This feature is automatically enabled whenever
    optimization is enabled.  There is no way (other than disabling
    optimization) of turning it off.

  * Profiling with gprof has been added.

    The use of gprof from profiling is now included in this release.


RDA Notes
---------

New in this release:

    * Software singlestep support added for LIW instructions.
    * Software singlestep support for SETLB and Lcc revised.  (The
      old code made some assumptions which turned out not to be true.)


GDB Notes
---------

New in this release:

    * Revise signal frame support to match corresponding kernel change.
    * Prologue analyzer revised to accomodate prologues found in
      position independent code.
    * Fixed prologue analyzer bug in which pattern leading up to an
      expected "fmov" is matched, but no "fmov" is found.


Kernel Notes
------------

Kernel changes from previous release:

    * Fixed PCREL relocs in module loading.
    * Print CPU model when booting.
    * Added context pointer as second argument to signal handlers.
    * Fixed flushing of signal return insns.
    * Added "cc" constraint to asm statements which modify flags.


GLibc Notes
-----------

Glibc changed from previous release:

    * Fixed CENABLE macro for linuxthreads. IT#87558
    * Fixed ptrace handling of strace follow fork.


LTP mmstress failure Notes
--------------------------

After exhausive testing, we have determined the LTP mmstress failure is
not a bug.  The testcase does the following:

  1) malloc a big chunk (~40MB)
  2) create/truncate a temp file (on the nfs rootfs)
  3) write the buffer from step 1 to the file.
  4) mmap the file (MAP_PRIVATE)
  5) startup 32 threads, each of which walks through a different
     part of the mmap'd space writing to a word in each page.

The system starts with 60MB free memory. The write potentially uses
up 40MB but as the NFS writes progress, pages can be reclaimed. As the
threads touch the mmap'd space, COW operations are triggered until all
40MB of that space gets mapped to physical pages. So there is a race
between the NFS writes completing and the COW operations allocating
pages. When the kernel has DEBUG_SLAB turned on, the COWs are slowed down,
but the NFS speed over the net is same. This turns out to be enough of
a difference to prevent the COWs from racing too far ahead of NFS and
hitting the OOM.  Turn off DEBUG_SLAB and the kernel runs faster, but NFS
is still subject to the same net/server delays, so the system runs into
the OOM-killer in that case. This is further evidenced by the testcase
passing when verbose output is enabled. This puts a printf after every
page touch by the threads which prevents the COWs from getting too far
ahead of NFS.


Debugging Shared Libraries on a Remote Target with GDB
------------------------------------------------------

Using GDB to debug programs which make use of shared libraries should
be largely automatic.  I.e, during the course of debugging, no user
intervention should normally be required to cause a shared library's
symbol table to be loaded and correctly relocated.  GDB will detect
when the remote target has loaded a new shared library and will
attempt to load a copy of that library using a location (path) on the
host's filesystem.

Since the target's shared library machinery specifies paths which may
only make sense on the target, GDB needs a mechanism for translating
the target specific paths into paths which are usable on the host
(since it is from the host that GDB loads the symbols associated with
a shared library).  GDB has two variables that may be set to cause
this to happen.  These are:

    - solib-absolute-prefix
    - solib-search-path

The string associated with "solib-absolute-prefix" is prepended to
the target specific path to form a host-specific path.  So, e.g, if
"solib-absolute-prefix" has been set to "/path/to/target-fs-root"
and GDB is attempting to load the symbols associated with
/lib/libc.so, prepending the value of "solib-absolute-prefix" yields
"/path/to/target-fs-root/lib/libc.so".  GDB uses this path on the
host system to (attempt to) load libc.so's symbols.

If GDB fails to load the shared library's symbols by prepending
"solib-absolute-prefix", it will strip off the directory specific
components from the path (yielding the shared library's basename)
and then prepend each of the paths found in the colon-separated
"solib-search-patch" variable, stopping on the first one that it
successfully opens.

"solib-absolute-prefix" is normally used in conjunction with "system"
libraries such as those found in /lib, /usr/lib, and other "standard"
locations for libraries.  If the shared library machinery communicates
an absolute path for a library to GDB, it is usually best to have a
directory on the host which is populated with the libraries found on
the target, taking care to preserve the directory structure associated
with those libraries.  E.g, suppose you had the following three 
libraries on the target:

        /lib/libc.so
        /usr/lib/libdb.so
        /usr/local/lib/libmp3lame.so

Then, on the host, you might have the following isomorphic structure:

        /path/to/target-fs-root/lib/libc.so
        /path/to/target-fs-root/usr/lib/libdb.so
        /path/to/target-fs-root/usr/local/lib/libmp3lame.so

In GDB (or in a .gdbinit file), you'd do:

    set solib-absolute-prefix /path/to/target-fs-root

"solib-relative-path" is normally used to locate application specific
libraries whose paths are specified to GDB as relative paths.

It is critical that the libraries on the target are kept in sync with 
those on the host.  If there's a mismatch, i.e, if the target contains 
a newer version of a library than the host, or vice versa, then strange
errors may occur.  E.g, it's possible to see an illegal instruction 
exception, segmentation fault, or other memory related fault on the 
target due to a breakpoint being placed at incorrect locations.  The 
debugging of multi-threaded programs almost always requires that the 
shared library machinery is working correctly, so if you're having 
trouble debugging a multi-threaded program, a good place to start 
diagnosing the problem is to make sure that "solib-absolute-prefix" 
and "solib-absolute-path" are set correctly and that the contents of 
the libraries on the target match the contents of the corresponding 
host-located libraries exactly.


Debugging with debuginfo files
------------------------------
GDB will automatically use separate debug files under either of the 
following circumstances:

  1.  The debug files are placed in the same directory as the libraries
      to be debugged.

  2.  The debug files are in a subdirectory, named .debug, of the 
      directory containing the libraries.

See docs/README.rpmbuildroot for instructions on installing debug files
when building the root file system.


glibc 2.3.4 on AM33_2.0 platform
--------------------------------

Glibc has been updated to support nptl and tls. NPTL/TLS system 
libraries are installed in /lib/tls and linuxthreads/non-TLS versions 
of those libraries are installed in /lib.  By default, the NPTL/TLS 
versions are used. Existing linuxthread programs are forward compatible
with the NPTL libraries.  Those programs may also be run using the 
linuxthreads libraries by setting an environment variable:

 # LD_ASSUME_KERNEL=2.4.19 <application name>


The am33_2.0-linux-gnu toolchain uses setjmp/longjmp based frame 
unwinding to support exception handling. NPTL based glibc accesses the 
sjlj unwinding interfaces via a gcc provided library (libgcc_s.so). 
Glibc will dlopen this library, the first time a process needs to use 
the unwinding interface. This means that a free fd is required when the
unwinding interface in first used by a program.  This will cause an 
error in programs that use up all available fds, then call a libc 
function that uses the libgcc_s.so interfaces. In addition, libgcc_s.so
uses up a pthread TSD key to create a thread-specific list of frame 
contexts. This will cause a failure in programs which try to create 
PTHREAD_KEYS_MAX keys because libgcc_s.so uses one key.