gdb/gdb-bz594560-core-vs-process.patch
2010-07-11 18:06:33 +00:00

165 lines
5.7 KiB
Diff

--- ./gdb/doc/gdb.texinfo 2010-05-24 19:37:01.000000000 +0200
+++ ./gdb/doc/gdb.texinfo 2010-05-24 19:38:56.000000000 +0200
@@ -14768,33 +14768,21 @@ and @code{show architecture}.
@cindex active targets
@cindex multiple targets
-There are three classes of targets: processes, core files, and
-executable files. @value{GDBN} can work concurrently on up to three
-active targets, one in each class. This allows you to (for example)
-start a process and inspect its activity without abandoning your work on
-a core file.
-
-For example, if you execute @samp{gdb a.out}, then the executable file
-@code{a.out} is the only active target. If you designate a core file as
-well---presumably from a prior run that crashed and coredumped---then
-@value{GDBN} has two active targets and uses them in tandem, looking
-first in the corefile target, then in the executable file, to satisfy
-requests for memory addresses. (Typically, these two classes of target
-are complementary, since core files contain only a program's
-read-write memory---variables and so on---plus machine status, while
-executable files contain only the program text and initialized data.)
-
-When you type @code{run}, your executable file becomes an active process
-target as well. When a process target is active, all @value{GDBN}
-commands requesting memory addresses refer to that target; addresses in
-an active core file or executable file target are obscured while the
-process target is active.
-
-Use the @code{core-file} and @code{exec-file} commands to select a new
-core file or executable target (@pxref{Files, ,Commands to Specify
-Files}). To specify as a target a process that is already running, use
-the @code{attach} command (@pxref{Attach, ,Debugging an Already-running
-Process}).
+There are multiple classes of targets such as: processes, executable files or
+recording sessions. Core files belong to the process class, there can be
+active only one of a core or a running process. Otherwise @value{GDBN} can
+work concurrently on multiple active targets, one in each class. This allows
+you to (for example) start a process and inspect its activity while still
+having access to the executable file after the process finishes. Or if you
+start process recording (@pxref{Reverse Execution}) and @code{reverse-step}
+there you are presented a virtual layer of the recording target while the
+process target remains stopped at the chronologically last point of the process
+execution.
+
+Use the @code{core-file} and @code{exec-file} commands to select a new core
+file or executable target (@pxref{Files, ,Commands to Specify Files}). To
+specify as a target a process that is already running, use the @code{attach}
+command (@pxref{Attach, ,Debugging an Already-running Process}).
@node Target Commands
@section Commands for Managing Targets
--- ./gdb/infcmd.c 2010-05-24 19:37:01.000000000 +0200
+++ ./gdb/infcmd.c 2010-05-24 19:41:21.000000000 +0200
@@ -483,6 +483,13 @@ run_command_1 (char *args, int from_tty,
dont_repeat ();
+ if (core_bfd)
+ {
+ core_file_command (NULL, from_tty);
+ if (core_bfd)
+ warning (_("Core file not unloaded."));
+ }
+
kill_if_already_running (from_tty);
init_wait_for_inferior ();
@@ -2373,6 +2380,13 @@ attach_command (char *args, int from_tty
error (_("Not killed."));
}
+ if (core_bfd)
+ {
+ core_file_command (NULL, from_tty);
+ if (core_bfd)
+ warning (_("Core file not unloaded."));
+ }
+
/* Clean up any leftovers from other runs. Some other things from
this function should probably be moved into target_pre_inferior. */
target_pre_inferior (from_tty);
--- ./gdb/testsuite/gdb.base/corefile.exp 2010-01-09 01:14:11.000000000 +0100
+++ ./gdb/testsuite/gdb.base/corefile.exp 2010-05-24 19:38:56.000000000 +0200
@@ -182,3 +182,62 @@ gdb_load ${binfile}
gdb_test "up" "#\[0-9\]* *\[0-9xa-fH'\]* in .* \\(.*\\).*" "up in corefile.exp (reinit)"
gdb_test "core" "No core file now."
+
+
+# Test a run (start) command will clear any loaded core file.
+
+gdb_test "core-file $corefile" "Core was generated by .*" "run: load core again"
+gdb_test "info files" "\r\nLocal core dump file:\r\n.*" "run: sanity check we see the core file"
+
+set test "run: with core"
+if [runto_main] {
+ pass $test
+} else {
+ fail $test
+}
+
+set test "run: core file is cleared"
+gdb_test_multiple "info files" $test {
+ "\r\nLocal core dump file:\r\n.*\r\n$gdb_prompt $" {
+ fail $test
+ }
+ "\r\n$gdb_prompt $" {
+ pass $test
+ }
+}
+
+gdb_exit
+
+
+# Test an attach command will clear any loaded core file.
+
+if ![is_remote target] {
+ set test "attach: spawn sleep"
+ set res [remote_spawn host "$binfile sleep"];
+ if { $res < 0 || $res == "" } {
+ perror "$test failed."
+ fail $test
+ return
+ }
+ set pid [exp_pid -i $res]
+ # We do not care of the startup phase where it will be caught.
+
+ gdb_start
+
+ gdb_test "core-file $corefile" "Core was generated by .*" "attach: load core again"
+ gdb_test "info files" "\r\nLocal core dump file:\r\n.*" "attach: sanity check we see the core file"
+
+ gdb_test "attach $pid" "Attaching to process $pid\r\n.*" "attach: with core"
+
+ set test "attach: core file is cleared"
+ gdb_test_multiple "info files" $test {
+ "\r\nLocal core dump file:\r\n.*\r\n$gdb_prompt $" {
+ fail $test
+ }
+ "\r\n$gdb_prompt $" {
+ pass $test
+ }
+ }
+
+ gdb_exit
+}
--- ./gdb/testsuite/gdb.base/coremaker.c 2010-01-01 08:32:00.000000000 +0100
+++ ./gdb/testsuite/gdb.base/coremaker.c 2010-05-24 19:38:56.000000000 +0200
@@ -133,8 +133,14 @@ func1 ()
func2 ();
}
-int main ()
+int
+main (int argc, char **argv)
{
+ if (argc == 2 && strcmp (argv[1], "sleep") == 0)
+ {
+ sleep (60);
+ return 0;
+ }
mmapdata ();
func1 ();
return 0;