diff options
author | Pedro Alves <palves@redhat.com> | 2014-08-21 11:36:59 +0100 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2014-08-21 11:36:59 +0100 |
commit | a8454a7c5a2254b249b1bac34e7cef1438bca9f2 (patch) | |
tree | 4aa6b59baf5361a7533d81eb714d448c61f422b9 /gdb/utils.h | |
parent | c542398150124a0b5adbbeeb274e55ee56d3120a (diff) | |
download | gdb-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