aboutsummaryrefslogtreecommitdiff
path: root/gdb/utils.h
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2014-08-21 11:36:59 +0100
committerPedro Alves <palves@redhat.com>2014-08-21 11:36:59 +0100
commita8454a7c5a2254b249b1bac34e7cef1438bca9f2 (patch)
tree4aa6b59baf5361a7533d81eb714d448c61f422b9 /gdb/utils.h
parentc542398150124a0b5adbbeeb274e55ee56d3120a (diff)
downloadgdb-a8454a7c5a2254b249b1bac34e7cef1438bca9f2.zip
gdb-a8454a7c5a2254b249b1bac34e7cef1438bca9f2.tar.gz
gdb-a8454a7c5a2254b249b1bac34e7cef1438bca9f2.tar.bz2
Remove useless gcore command detection
Checking whether the gcore command is included in the GDB build as proxy for checking whether core dumping is supported by the target is useless, as gcore.o has been in COMMON_OBS since git 9b4eba8e: 2009-10-26 Michael Snyder <msnyder@vmware.com> Hui Zhu <teawater@gmail.com> * Makefile.in (SFILES): Add gcore.c. (COMMON_OBS): Add gcore.o. * config/alpha/alpha-linux.mh (NATDEPFILES): Delete gcore.o. * config/alpha/fbsd.mh (NATDEPFILES): Ditto. ... IOW, the command is always included in the build. Instead, nowadays, tests bail out if actually trying to generate a core fails with an indication the target doesn't support it. See gdb_gcore_cmd and callers. Tested on x86_64 Fedora 20. gdb/testsuite/ChangeLog: * gdb.base/gcore-buffer-overflow.exp: Remove "help gcore" test. * gdb.base/gcore-relro-pie.exp: Likewise. * gdb.base/gcore-relro.exp: Likewise. * gdb.base/gcore.exp: Likewise. * gdb.base/print-symbol-loading.exp: Likewise. * gdb.threads/gcore-thread.exp: Likewise. * lib/gdb.exp (gdb_gcore_cmd): Don't expect "Undefined command".
Diffstat (limited to 'gdb/utils.h')
0 files changed, 0 insertions, 0 deletions