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