X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=gdb%2FPROBLEMS;h=77deedc057ee5c20c82e1e25fa52a6801ca58e62;hb=43c3a82e5ba7161808fcbd2e9ba570ee18170fa3;hp=49d27967daa04c3f5c1ccf9bb7f42ac559055229;hpb=0db712473f7746f65d119d2be2def54c8841c654;p=binutils-gdb.git diff --git a/gdb/PROBLEMS b/gdb/PROBLEMS index 49d27967daa..77deedc057e 100644 --- a/gdb/PROBLEMS +++ b/gdb/PROBLEMS @@ -1,32 +1,35 @@ - Known problems in GDB 5.2 + Known problems in GDB 6.0 See also: http://www.gnu.org/software/gdb/bugs/ +gdb/1091: Constructor breakpoints ignored +gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints -hppa2.0-hp-hpux10.20 --------------------- +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. -gdb/487: The top level make files used to build GDB are not compatible -with HP/UX make. As a workaround, use GNU make. +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. -gdb/486: The HP/UX C compiler defaults to K&R mode but GDB only builds -with an ISO C compiler. The top level configuration incorrectly sets -CC to `cc' instead of `cc -Ae'. As a workaround, the correct compiler -can be specified as part of the configuration vis: +gdb/1322: "internal-error: sect_index_text not initialized" after printing a java type - $ 'CC=cc -Ae' ./configure +When gdb debugs a Java program which uses shared libraries, it can +generate this internal error. +If you get this error when debugging Java, you can try working around +the problem by relinking your program with no shared libraries at all +(even the standard C library). With the GNU linker, use the "-static" +argument to do this. -s390*-*-* ---------- +You can also try this patch for gdb: -gdb/513: GDB does not build on s390 GNU/Linux. The problem should be -fixed in more recent sources. - - -i386-*-freebsd4.4* ------------------- - -gdb/455: GDB doesn't build on a FreeBSD 4.4-STABLE system. The -problem is still being investigated. + http://sources.redhat.com/ml/gdb-prs/2003-q3/msg00190.html