6.7 build breaks on i686
Version: 6.7 Compiler: gcc (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) System: i686-pc-linux-gnu While compiling the following file, `-Werror' is passed to compiler. Still gdb-6.7/bfd/elf32-i386.c: In function `elf_i386_tls_transition': gdb-6.7/bfd/elf32-i386.c:1174: warning: duplicate `const' gdb-6.7/bfd/elf32-i386.c:1174: warning: duplicate `const' make[4]: *** [elf32-i386.lo] Error 1 Preprocessed code contains the following. `bfd.h': typedef const struct reloc_howto_struct reloc_howto_type; `elf32-i386.c': const reloc_howto_type *from, *to; `reloc_howto_type' appears to be quite generic, the same in all builds. So this error warning should occur whenever compiling any code like that. ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
(void(**)()) still in 6.6
Version: 6.3, 6.4, 6.4.50.20060307-cvs, 6.6 In 6.6 it is just the same as in previous versions, and as described on Fri, 31 Mar 2006 22:12:41 +0400 ([EMAIL PROTECTED]). (gdb) p*(void(**)())$addr A syntax error in expression, near `*)())$addr'. ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
crash in expr eval
Version: 6.5, no changes Configuration: all `configure' args are srcdir, installation prefix. System: i686-pc-linux-gnu #0 check_typedef (type=0x0) at ../../share/src/gdb-6.5/gdb/gdbtypes.c:1384 #1 0x080ddc99 in coerce_ref (arg=0x84a13b0) at ../../share/src/gdb-6.5/gdb/value.c:1615 #2 0x080e3456 in value_assign (toval=0x84a13b0, fromval=0x84ca610) at ../../share/src/gdb-6.5/gdb/valops.c:535 #3 0x080e1603 in evaluate_subexp_standard (expect_type=0x0, exp=0x8dd0b18, pos=0xb484, noside=EVAL_NORMAL) at ../../share/src/gdb-6.5/gdb/eval.c:1486 #4 0x080ddf1d in evaluate_subexp (expect_type=0x0, exp=0x8dd0b18, pos=0xb484, noside=EVAL_NORMAL) at ../../share/src/gdb-6.5/gdb/eval.c:72 #5 0x080de0dd in evaluate_expression (exp=0x8dd0b18) at ../../share/src/gdb-6.5/gdb/eval.c:162 #6 0x080ec5ff in set_command ( exp=0x8dc14c7 $reva=Feval(Fcar(Fread_from_string(build_string(\(condition-case nil (princ (buffer-substring nil nil (get-buffer \\\*Disassemble*\\\))) (error nil))\),Qnil,Qnil))), from_tty=0) at ../../share/src/gdb-6.5/gdb/printcmd.c:1003 In `coerce_ref' `arg-type' is 0x0. Have saved core file, will post further details on request. ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
can not step
Versions: 6.3, 6.5. System: i686-pc-linux-gnu. Packages: kernel-2.6.3.27mdk-1-1mdk glibc-2.3.3-12.8.100mdk gcc-3.3.2-6mdk Built emacs 21.4a with that gcc, `CFLAGS=-g -O2'. Stopped in `decode_coding_iso2022', which does no system calls, consists entirely of cpu use. All attempts to step further would fail. `step', `next', `stepi' would behave exactly like `continue'. Observed that only on system with set of packages as above, and even there only with that debugged program. ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
gags on -pie executables
Version: 6.5 System: x86_64-unknown-linux-gnu fedora core 4 Compiler: gcc-4.0.0-8 gdb can not handle one sort of binary executables that are otherwise ran normally by the system. They are those linked with `-pie' passed to linking `cc'. They may also be detected by `file' reporting executable to be ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped (Otherwise, it reports them as) ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped Otherwise they are regular executables, having `main' and `_start' symbols, and having entry point at `_start'. System runs program built this way normally. Program may be built with debugging information (`-g'), and later assuming that. `at' gdb command completes normally, but `bt' does not show line numbers. Even `i sh' shows no shared libraries, though `ldd' shows that there should be some. `b' with line numbers completes normally, and then `c' outputs: Continuing. Warning: Cannot insert breakpoint 2. Error accessing memory address 0x6f66e: Input/output error. All of these commands break the same way even if using `r' instead of `at'. Once the program is relinked without `-pie', even from the same object files, gdb works normally. Such an executables are actually part of some systems. They are abundant in one installed from http://download.fedoraproject.org/pub/fedora/linux/core/4/x86_64/, (see http://fedoraproject.org/wiki/Distribution/Download#head-e82afb53c564fe4d3c977246c5760fad2edfccd9 for other ways to download). This includes, but not limited to, `/usr/bin/at', `/usr/bin/dig', `/usr/bin/host', `/usr/bin/omshell', `/usr/bin/svn'. (Hope that this is enough.) ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
(void(**)())
Versions: 6.3, 6.4, 6.4.50.20060307-cvs When current expression language is c, gdb considers the following type cast an error (gdb) p*(void(**)())$addr A syntax error in expression, near `*)())$addr'. Version 5.1 would process it the same way standard c implementations, that is, as `(void(*(*))())' cast. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
reading data members: `this' reference
Version: 6.3 On request will compose reproducing instructions with a smaller code example. For now, observed that on code of `kdecore' from kdelibs 3.2. (gdb) p(NETRootInfoPrivate*)(*(void**)($esp)-0x28) $69 = (NETRootInfoPrivate *) 0x810f5c0 (gdb) p $69-workarea Variable this is not available. `workarea' is a (data) field of `NETRootInfoPrivate' structure. Reading it should require nothing except address of that structure variable. But, instead, for some reason gdb tries to use `this' (pointer to class instance passed to class method that currently executes) - which is indeed not available at the moment due to some compiler optimizations. The worst is that the whole gdb expression evaluation terminates, not just error / warning is issued. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
`distclean' incomplete
Version: 6.3 `make distclean' leaves the following files in build directory. intl/config.h intl/config.status intl/stamp-h gdb/doc/gdb.info gdb/doc/gdb.info-1 gdb/doc/gdb.info-2 gdb/doc/gdb.info-3 gdb/doc/gdb.info-4 gdb/observer.h gdb/ada-lex.c gdb/observer.inc utils/sparclite/Makefile utils/sparclite/config.status utils/wince/config.status utils/wince/Makefile If a new gdb version is configured to build in the same directory, it may even break the build, in particular, because files left in build directory are obsolete wrt new version and gdb makefiles in that new version fail to notice that and rebuild them. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: never builds gdb.info
(although personally I think it's a wrong design): So do I. In particular, if `gdb.texinfo' or other `gdb.info' prerequisite was changed, will `make install' install updated `gdb.info' version? Putting checking this in my `todo' list. The worst is that distribution does not even contain `INSTALL' file to document this, um, irregularity. make info to get the documentation built. Or remove `gdb.info' from src dir, and `make gdb-cfg.texi gdb.info' in build one. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
never builds gdb.info
Neither http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=createdatabase=gdbreturn_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26user%3Dguest%26password%3Dguest%26cmd%3Dquery referenced by http://www.gnu.org/software/gdb/bugs/ sends confirmation message about submitted report, nor the submitted report can be found in the database. Sending it this way. Version: 6.3 `make' does not even try to build `gdb.info'. ../share/gdb-6.3/configuremake rm ../share/gdb-6.3/gdb/doc/gdb.info* make ls ../share/gdb-6.3/gdb/doc/gdb.info* ls: ../share/gdb-6.3/gdb/doc/gdb.info*: No such file or directory ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
gdb.info: no gdb-cfg.texi
Version: 6.3 Can not rebuild `gdb.info' even by explicit command. At least one required file is neither in distribution nor gets built. bash ../share/gdb-6.3/configuremake bash rm ../share/gdb-6.3/gdb/doc/gdb.info* bash pushd gdb/doc;make ../../../share/gdb-6.3/gdb/doc/gdb.info;popd makeinfo ../../../share/gdb-6.3/gdb/doc/gdb.texinfo -o ../../../share/gdb-6.3/gdb/doc/gdb.info ../../../share/gdb-6.3/gdb/doc/gdb.texinfo:11: @include `gdb-cfg.texi': No such file or directory. Will post the ensuing cascade of warnings and errors on request. bash find . ../share/gdb-6.3 -type f -name gdb-cfg.texi outputs nothing. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
