aboutsummaryrefslogtreecommitdiff
path: root/gdb/linux-nat.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2020-01-10 20:05:46 +0000
committerPedro Alves <palves@redhat.com>2020-01-10 20:05:46 +0000
commitbd420a2dfff64978feb1659d3b77c7601b98463f (patch)
treef5af9eee03a3cee5a1f8808ecc444d7755f18794 /gdb/linux-nat.c
parentddf5db90a175756b3a5c39ee87d549d9f9d09d28 (diff)
downloadgdb-bd420a2dfff64978feb1659d3b77c7601b98463f.zip
gdb-bd420a2dfff64978feb1659d3b77c7601b98463f.tar.gz
gdb-bd420a2dfff64978feb1659d3b77c7601b98463f.tar.bz2
Delete unnecessary code from kill_command
I believe this comment: /* Killing off the inferior can leave us with a core file. If so, print the state we are left in. */ Referred to the fact that a decade ago, by design, GDB would let you type "run" when debugging a core dump, keeping the core open. That "run" would push a process_stratum target on the target stack for the live process, and, the core would remain open -- we used to have a core_stratum. When the live process was killed/detached or exited, GDB would go back to debugging the core, since the core_stratum target was now at the top of the stack. That design had a number of problems, see here for example: https://sourceware.org/ml/gdb-patches/2008-08/msg00290.html In 2010, core_stratum was finaly eliminated and cores now have process_stratum too, with commit c0edd9edadfe ("Make core files the process_stratum."). Pushing a live process on the stack while you're debugging a core discards the core completely. I also thought that this might be in use with checkpoints, but it does not -- "kill" when you have multiple checkpoints kills all the checkpoints. gdb/ChangeLog: 2020-01-10 Pedro Alves <palves@redhat.com> * infcmd.c (kill_command): Remove dead code.
Diffstat (limited to 'gdb/linux-nat.c')
0 files changed, 0 insertions, 0 deletions