79 lines
3.1 KiB
Plaintext
79 lines
3.1 KiB
Plaintext
|
|
Known problems in GDB 6.1
|
|
|
|
See also: http://www.gnu.org/software/gdb/bugs/
|
|
|
|
mips*-*-*
|
|
powerpc*-*-*
|
|
sparc*-*-*
|
|
|
|
GDB's SPARC, MIPS and PowerPC targets, in 6.0, have not been updated
|
|
to use the new frame mechanism.
|
|
|
|
People encountering problems with these targets should consult GDB's
|
|
web pages and mailing lists (http://www.gnu.org/software/gdb/) to see
|
|
if there is an update.
|
|
|
|
*** Regressions since gdb 6.0
|
|
|
|
gdb/826: variables in C++ namespaces have to be enclosed in quotes
|
|
|
|
When referring to a variable in C++ code that is inside a
|
|
namespace, you have to put it inside single quotes.
|
|
|
|
gdb/931: GDB could be more generous when reading types C++ templates on input
|
|
|
|
When the user types a template, GDB frequently requires the type to be
|
|
typed in a certain way (e.g. "const char*" as opposed to "const char *"
|
|
or "char const *" or "char const*").
|
|
|
|
gdb/1505: [regression] gdb prints a bad backtrace for a thread
|
|
|
|
When backtracing a thread, gdb doesn't stop until it hits garbage.
|
|
This is sensitive to the operating system and thread library.
|
|
|
|
gdb/1512: no canonical way to output names of C++ types
|
|
|
|
We currently don't have any canonical way to output names of C++ types.
|
|
E.g. "const char *" versus "char const *"; more subtleties arise when
|
|
dealing with templates.
|
|
|
|
gdb/1516: [regression] local classes, gcc 2.95.3, dwarf-2
|
|
|
|
With gcc 2.95.3 and the dwarf-2 debugging format, classes which are
|
|
defined locally to a function include the demangled name of the function
|
|
as part of their name. For example, if a function "foobar" contains a
|
|
local class definition "Local", gdb will say that the name of the class
|
|
type is "foobar__Fi.0:Local".
|
|
|
|
This applies only to classes where the class type is defined inside a
|
|
function, not to variables defined with types that are defined somewhere
|
|
outside any function (which most types are).
|
|
|
|
gdb/1560: Control-C does not always interrupt GDB.
|
|
|
|
When GDB is busy processing a command which takes a long time to
|
|
complete, hitting Control-C does not have the expected effect.
|
|
The command execution is not aborted, and the "QUIT" message confirming
|
|
the abortion is displayed only after the command has been completed.
|
|
|
|
*** Regressions since gdb 5.3
|
|
|
|
gdb/1091: Constructor breakpoints ignored
|
|
gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints
|
|
|
|
When gcc 3.x compiles a C++ constructor or C++ destructor, it generates
|
|
2 or 3 different versions of the object code. These versions have
|
|
unique mangled names (they have to, in order for linking to work), but
|
|
they have identical source code names, which leads to a great deal of
|
|
confusion. Specifically, if you set a breakpoint in a constructor or a
|
|
destructor, gdb will put a breakpoint in one of the versions, but your
|
|
program may execute the other version. This makes it impossible to set
|
|
breakpoints reliably in constructors or destructors.
|
|
|
|
gcc 3.x generates these multiple object code functions in order to
|
|
implement virtual base classes. gcc 2.x generated just one object code
|
|
function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
|
|
ABI for C++ which requires multiple object code functions.
|
|
|