1.63.  gdb

Normally, static variables always have the same debugging information for each possible constructor/destructor implementation kind, which allows the compiler to keep their DIE (debugging information entry) only in the single abstract instance of the constructor. However, GDB did not automatically inherit whole DIEs from the abstract instances to the concrete instances. As such, the static variables in C++ constructors were not visible from GDB. With this update, GDB now inherits whole DIEs to ensure that static variables do not become inaccessible. (BZ#445912)

GDB now supports the use of 64-bit ELF files for 32-bit platforms (i.e. elf64-i386). (BZ#457187)

It was possible for GDB to print an error when trying to access an allocatable or otherwise dynamic array or string variable in Fortran. This was because GDB did not account for the fact that the lower bound for Fortran arrays was 1 (rather than 0). This made it possible for array size calculations to result in invalid values (i.e. too high) when allocating unbound or dynamically-bound Fortran arrays. This release corrects the way GDB processes Fortran arrays; it also adds functions to verify the validity of a calculated array size first before attempting to allocate it. (BZ#459380)

Variables imported from Fortran modules can be now accessed from GDB with the same scope as the program being debugged. (BZ#466118 , BZ #457793)

Variables shared by Fortran "common blocks" can be now accessed from GDB with the same scope as the program being debugged. Further, common blocks valid in the current program scope can be printed using the GDB command 'info common'. (BZ#459762)

Allocatable arrays, objects with assumed size, and pointers to objects can be now accessed from GDB in the same manner that they are accessed from the program being debugged. (BZ#460250 , BZ#459952 , BZ#465301 , BZ#505333)

Variables of type 'logical (kind=8)' can be now accessed from GDB. (BZ#465310)

For external references, GCC does not produce DWARF debug information. As a result, GDB could not access Thread Local Storage (TLS) variables from a local source file if those variables were defined in a different source file. This made it possible for certain memory addresses to become unaccessible to GDB. With this release, GDB can now process TLS variables using ELF structures instead of DWARF; as such, GDB can now access TLS variables regardless of where those variables were defined. (BZ#494412)

Running gcore (or any 'attach' or 'detach' command sequence) on a multi-threaded process that was halted with 'kill -STOP' could unexpectedly resume some of that process's threads. This behavior was caused by a kernel bug (present in upstream version 2.6.29) that remained unfixed in Red Hat Enterprise Linux 5 kernels to maintain backward compatibility. While this update does not fix the kernel bug, it applies a GDB workaround that ensures threads from a halted multi-threaded process do not unexpectedly resume. (BZ#498595)