usefulness of "you won't be able to access this core file until you terminate your ..."

[Pedro Alves <pedro at codesourcery dot com>]

Can anybody explain to me the usefulness of keeping an upper layer around when
opening a new core file?  We're conceptually loading a new inferior, and 
setting up a new target stack to access it.  Why would you want to leave
an inferface into the previous inferior, which surelly may not make
sense for the new inferior?

If I'm debugging a multi-threaded OpenBSD core, which loads bsd-uthreads,
and the I do "core single-thread.core", to load a core file for a program
that didn't link with the thread library, I get that warning.  But, why would
anybody want to keep any target_stratum >= process_stratum around then ?

In corelow.c:

static void
core_open (filename, from_tty)
     char *filename;
     int from_tty;
{
  (...)

  ontop = !push_target (&core_ops);
  discard_cleanups (old_chain);

  (...)

  /* Build up thread list from BFD sections. */

  init_thread_list ();
  bfd_map_over_sections (core_bfd, add_to_thread_list,
                         bfd_get_section_by_name (core_bfd, ".reg"));

  if (ontop)
    {
      (...)
    }
  else
    {
      warning (
"you won't be able to access this core file until you terminate\n\
your %s; do ``info files''", target_longname);
    }
}

IMO, the pop_target below should be make unconditional, since
when I'm debugging a multi-threaded core, even though I loaded
the thread_stratum layer, it doesn't have target_has_execution.
And, it should be a pop_all_targets or similar call.  The question is,
again, why would anybody want to leave the thread_stratum, or anything
else above core_stratum around?

 void
 target_preopen (int from_tty)
 {
   dont_repeat ();

   if (target_has_execution)
     {
       if (!from_tty
           || query (_("A program is being debugged already.  Kill it? ")))
 	target_kill ();
       else
 	error (_("Program not killed."));
     }

   /* Calling target_kill may remove the target from the stack.  But if
      it doesn't (which seems like a win for UDI), remove it now.  */

   if (target_has_execution)
     pop_target ();

   target_pre_inferior (from_tty);
 }

This issue doesn't happen normally when going from a running
multi-threaded inferior -> single-threaded core, because the
target_kill above pops the whole stack out.

Linux: running thread-db app -> single-threaded core 

>gdb --quiet /home/pedro/gdb/tests/threads
(gdb) start
Breakpoint 1 at 0x400640: file threads.c, line 35.
Starting program: /home/pedro/gdb/tests/threads
[Thread debugging using libthread_db enabled]
[New Thread 0x7f7eaf8916e0 (LWP 17234)]
[Switching to Thread 0x7f7eaf8916e0 (LWP 17234)]
main () at threads.c:35
35          long i = 0;
(gdb) maint print target-stack
The current target stack is:
  - multi-thread (multi-threaded child process.)
  - child (Unix child process)
  - exec (Local exec file)
  - None (None)
(gdb) core gdb/gdb.core
A program is being debugged already.  Kill it? (y or n) y
warning: core file may not match specified executable file.
warning: Temporarily disabling breakpoints for unloaded shared 
library "/lib/libpthread.so.0"
warning: Temporarily disabling breakpoints for unloaded shared 
library "/lib/libc.so.6"
Symbols already loaded for /lib64/ld-linux-x86-64.so.2

Core was generated by `/home/pedro/gdb/multi_process/build/gdb/gdb'.
Program terminated with signal 5, Trace/breakpoint trap.
[New process 16607]
#0  0x000000000044ee87 in ?? ()
(gdb) maint print target-stack
The current target stack is:
  - core (Local core dump file)
  - exec (Local exec file)
  - None (None)
(gdb)    

OpenBSD multi-threaded core -> single-threaded core

>./gdb --quiet ./crash -c ./crash.core
Reading symbols from /usr/lib/libpthread.so.9.0...done.
Loaded symbols for /usr/lib/libpthread.so.9.0
Symbols already loaded for /usr/lib/libpthread.so.9.0
Reading symbols from /usr/lib/libc.so.43.0...done.
Loaded symbols for /usr/lib/libc.so.43.0
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
Core was generated by `crash'.
Program terminated with signal 11, Segmentation fault.
[New process 1, thread 0x8874a400]
...
#0  _thread_kern_sched (scp=0xcfbf077c) 
at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
482     /usr/src/lib/libpthread/uthread/uthread_kern.c: No such file or 
directory.
        in /usr/src/lib/libpthread/uthread/uthread_kern.c
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; 
input not from terminal]
Function "info_command" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; 
input not from terminal]
/net/home/pedro/gdb/multi_process/build-openbsd43/gdb/.gdbinit:8: Error in 
sourced command file:
No breakpoint number 0.
(gdb) maint print target-stack
The current target stack is:
  - bsd-uthreads (BSD user-level threads)
  - core (Local core dump file)
  - exec (Local exec file)
  - None (None)

(gdb) core crashst.core
Core was generated by `crashst'.
Program terminated with signal 11, Segmentation fault.
warning: you won't be able to access this core file until you terminate
your BSD user-level threads; do ``info files''
(gdb) maint print target-stack
The current target stack is:
  - bsd-uthreads (BSD user-level threads)
  - core (Local core dump file)
  - exec (Local exec file)
  - None (None)

??????

I can come up with more weird cases:

target remote -> target core

shell1$ ./gdbserver :9999 ./gdbserver

shell2$ gdb --quiet ./gdbserver/gdbserver
(gdb) tar remote :9999
Remote debugging using :9999
[New Thread 17988]
0x00007f9d5e167a60 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) core gdb.core
A program is being debugged already.  Kill it? (y or n) y
warning: core file may not match specified executable file.
Symbols already loaded for /lib64/ld-linux-x86-64.so.2

Core was generated by `/home/pedro/gdb/multi_process/build/gdb/gdb'.
Program terminated with signal 5, Trace/breakpoint trap.
[New process 16607]
#0  0x000000000044ee87 in ?? ()
(gdb)       

Ok, that got rid of the remote target due to having target_has_execution.

But,

target extended-remote, no inferior -> target core

shell1$ ./gdbserver --multi :9999

shell2$ gdb
(gdb) tar extended-remote :9999
Remote debugging using :9999
(gdb) core gdb.core
(no debugging symbols found)
Core was generated by `/home/pedro/gdb/multi_process/build/gdb/gdb'.
Program terminated with signal 5, Trace/breakpoint trap.
[New Thread 16607]
warning: you won't be able to access this core file until you terminate
your Extended remote serial target in gdb-specific protocol; do ``info files''
Remote failure reply: E01
(gdb)

(Geesh, we really should split the notion of target interface vs
target inferior).

-- 
Pedro Alves