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