--- ./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;