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

[Pedro Alves <pedro at codesourcery dot com>]

I apologise, if I sounded ranty.  It wasn't intended.  I was really
surprised to see this behaviour.  :-(

Here's a patch to fix the issues above:
 [Get rid of previous targets in target_preopen]
 http://sourceware.org/ml/gdb-patches/2008-08/msg00292.html

Thanks,
-- 
Pedro Alves

On Monday 11 August 2008 01:31:54, Pedro Alves wrote:
> 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