198944Sobrien 2130803Smarcel Known problems in GDB 6.1 398944Sobrien 498944Sobrien See also: http://www.gnu.org/software/gdb/bugs/ 598944Sobrien 698944Sobrien 7130803Smarcel*** Build problems 898944Sobrien 9130803Smarcelbuild/1458: comple failed on hpux11 1098944Sobrien 11130803SmarcelGDB 6.1 is known to have build problems on HP/UX 11.00 using the 12130803Smarcelvendor supplied compilers (GDB does build on HP/UX 11.11, and using 13130803SmarcelGCC). 1498944Sobrien 15130803Smarcel*** Misc 1698944Sobrien 17130803Smarcelgdb/1560: Control-C does not always interrupt GDB. 1898944Sobrien 19130803SmarcelWhen GDB is busy processing a command which takes a long time to 20130803Smarcelcomplete, hitting Control-C does not have the expected effect. 21130803SmarcelThe command execution is not aborted, and the "QUIT" message confirming 22130803Smarcelthe abortion is displayed only after the command has been completed. 2398944Sobrien 24130803Smarcel*** C++ support 2598944Sobrien 26130803Smarcelgdb/931: GDB could be more generous when reading types C++ templates on input 2798944Sobrien 28130803SmarcelWhen the user types a template, GDB frequently requires the type to be 29130803Smarceltyped in a certain way (e.g. "const char*" as opposed to "const char *" 30130803Smarcelor "char const *" or "char const*"). 3198944Sobrien 32130803Smarcelgdb/1512: no canonical way to output names of C++ types 33130803Smarcel 34130803SmarcelWe currently don't have any canonical way to output names of C++ types. 35130803SmarcelE.g. "const char *" versus "char const *"; more subtleties arise when 36130803Smarceldealing with templates. 37130803Smarcel 38130803Smarcelgdb/1516: [regression] local classes, gcc 2.95.3, dwarf-2 39130803Smarcel 40130803SmarcelWith gcc 2.95.3 and the dwarf-2 debugging format, classes which are 41130803Smarceldefined locally to a function include the demangled name of the function 42130803Smarcelas part of their name. For example, if a function "foobar" contains a 43130803Smarcellocal class definition "Local", gdb will say that the name of the class 44130803Smarceltype is "foobar__Fi.0:Local". 45130803Smarcel 46130803SmarcelThis applies only to classes where the class type is defined inside a 47130803Smarcelfunction, not to variables defined with types that are defined somewhere 48130803Smarceloutside any function (which most types are). 49130803Smarcel 50130803Smarcelgdb/1588: names of c++ nested types in casts must be enclosed in quotes 51130803Smarcel 52130803SmarcelYou must type 53130803Smarcel (gdb) print ('Foo::Bar') x 54130803Smarcelor 55130803Smarcel (gdb) print ('Foo::Bar' *) y 56130803Smarcelinstead of 57130803Smarcel (gdb) print (Foo::Bar) x 58130803Smarcelor 59130803Smarcel (gdb) print (Foo::Bar *) y 60130803Smarcelrespectively. 61130803Smarcel 62130803Smarcelgdb/1091: Constructor breakpoints ignored 63130803Smarcelgdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints 64130803Smarcel 65130803SmarcelWhen gcc 3.x compiles a C++ constructor or C++ destructor, it generates 66130803Smarcel2 or 3 different versions of the object code. These versions have 67130803Smarcelunique mangled names (they have to, in order for linking to work), but 68130803Smarcelthey have identical source code names, which leads to a great deal of 69130803Smarcelconfusion. Specifically, if you set a breakpoint in a constructor or a 70130803Smarceldestructor, gdb will put a breakpoint in one of the versions, but your 71130803Smarcelprogram may execute the other version. This makes it impossible to set 72130803Smarcelbreakpoints reliably in constructors or destructors. 73130803Smarcel 74130803Smarcelgcc 3.x generates these multiple object code functions in order to 75130803Smarcelimplement virtual base classes. gcc 2.x generated just one object code 76130803Smarcelfunction with a hidden parameter, but gcc 3.x conforms to a multi-vendor 77130803SmarcelABI for C++ which requires multiple object code functions. 78130803Smarcel 79130803Smarcel*** Stack backtraces 80130803Smarcel 81130803SmarcelGDB's core code base has been updated to use a new backtrace 82130803Smarcelmechanism. This mechanism makes it possible to support new features 83130803Smarcelsuch DWARF 2 Call Frame Information (which in turn makes possible 84130803Smarcelbacktraces through optimized code). 85130803Smarcel 86130803SmarcelSince this code is new, it is known to still have a few problems: 87130803Smarcel 88130803Smarcelgdb/1505: [regression] gdb prints a bad backtrace for a thread 89130803Smarcel 90130803SmarcelWhen backtracing a thread, gdb does not stop when it reaches the 91130803Smarceloutermost frame, instead continuing until it hits garbage. This is 92130803Smarcelsensitive to the operating system and thread library. 93130803Smarcel 94130803Smarcelhppa*-*-* 95130803Smarcelmips*-*-* 96130803Smarcel 97130803SmarcelThe MIPS and HPPA backtrace code has only very recently been updated 98130803Smarcelto use GDB's new frame mechanism. At present there are still a few 99130803Smarcelproblems, in particular backtraces through signal handlers do not 100130803Smarcelwork. 101130803Smarcel 102130803SmarcelPeople encountering problems with these architectures should consult 103130803SmarcelGDB's web pages and mailing lists (http://www.gnu.org/software/gdb/) 104130803Smarcelto see if there are updates. 105130803Smarcel 106130803Smarcelpowerpc*-*-* 107130803Smarcel 108130803SmarcelPowerPC architecture support, in 6.1, does not use the new frame code. 109130803Smarcel 110130803SmarcelFortunately, PowerPC architecture support, in GDB's mainline sources, 111130803Smarcelhave been updated. People encountering problems should consider 112130803Smarceldownloading a more current snapshot of GDB 113130803Smarcel(http://www.gnu.org/software/gdb/current/). 114