mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-30 12:44:10 +08:00
775a3298dc
This new test fails on i686 buildbot slaves, (gdb) core-file /home/gdb-buildbot-2/fedora-x86-64-2/fedora-i686/build/gdb/testsuite/gdb.arch/i386-biarch-core.core "/home/gdb-buildbot-2/fedora-x86-64-2/fedora-i686/build/gdb/testsuite/gdb.arch/i386-biarch-core.core" is not a core dump: File format not recognized (gdb) FAIL: gdb.arch/i386-biarch-core.exp: core-file There are two problems: (1) The testcase did not really test if elf64-i386 is supported by GDB (BFD). That was OK for a Fedora testcase but I forgot about it when submitting it upstream. I haven't really verified if the GNU target is elf64-little but it seems so, no other one seems suitable from: elf32-x86-64 elf64-big elf64-k1om elf64-l1om elf64-little elf64-x86-64 pei-x86-64 (2) The output of the "core-file" command itself can be arbitrary as the elf64-i386 file with x86_64 registers is really broken; but that does not matter much, important is the following test whether core file memory is readable. ./configure --enable-64-bit-bfd (gdb) core-file /home/jkratoch/redhat/gdb-test-build32-plus64/gdb/testsuite/gdb.arch/i386-biarch-core.core^M warning: Couldn't find general-purpose registers in core file.^M Failed to read a valid object file image from memory.^M warning: Couldn't find general-purpose registers in core file.^M #0 <unavailable> in ?? ()^M (gdb) FAIL: gdb.arch/i386-biarch-core.exp: core-file x/i 0x400078^M 0x400078: hlt ^M (gdb) PASS: gdb.arch/i386-biarch-core.exp: .text is readable I do not know much dejagnu but I expect 'istarget' tests against the site.exp 'target_triplet' content which is set to the primary GDB target (--target=...). GDB is normally never configured for primary target elf64-i386, I think BFD does not know such explicit target, it gets recognized as elf64-little. In fact many testfiles of the GDB testsuite are wrong as they require 'istarget' (therefore primary GDB target) even for just loading arch specific files which would be sufficient with secondary target (--enable-targets=...) support. This my new patch removes this 'istarget' check as it is IMO unrelated to what we need to test. Although you are right we do 'x/i' and test for 'hlt' so I think we should test also for available 'set architecture i386'. We could also test by 'x/bx' instead of 'x/i' to avoid such additional test/requirement. This testcase comes from a different bug from 2009: https://bugzilla.redhat.com/show_bug.cgi?id=457187 http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=94cd124608bf0dd359cb48a710800d72c21b30c3 That bug has been fixed in the meantime but the same testcase was reproducing this new different bug - internal error regression - so I submitted it. We can remove the "x/bx $address" test but it was useful for the previous bug from 2009 as that time the internal error regression did not happen, just the core file was not recognized (which would not be detected by the proposed ignoring of the "core-file" command output) and so the core file was not available. That can be tested by the "x/bx $address" test. gdb/testsuite/ChangeLog 2015-07-16 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.arch/i386-biarch-core.exp: Replace istarget by "complete set gnutarget". Remove expectation for the "core-file" command. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
ylwrap |
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.