aboutsummaryrefslogtreecommitdiff
path: root/include
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 /include
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 'include')
0 files changed, 0 insertions, 0 deletions