This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Forbid run with a core file loaded
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Date: Fri, 21 May 2010 16:06:07 +0100
- Subject: Re: [patch] Forbid run with a core file loaded
- References: <20100521134718.GA17157@host0.dyn.jankratochvil.net>
On Friday 21 May 2010 14:47:19, Jan Kratochvil wrote:
> Hi,
>
> there is already a protection against loading a core file when a program is
> running.
>
> But one still can now run a program when a core file is loaded. Moreover GDB
> then crashes on `quit'.
>
> (gdb) file sleep
> [...]
> (gdb) start
> [...]
> (gdb) core-file core.5841
> A program is being debugged already. Kill it? (y or n) y
> [...]
> Program terminated with signal 11, Segmentation fault.
> [...]
> (gdb) start
> Starting program: /bin/sleep
> ^^^^^^^^^^^^^^^^ !!!
That's sort of expected. From gdb.texinfo:
"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."
This doesn't, and I think never has worked 100% correctly, except
maybe on single-threaded targets, on older GDBs.
Nowadays, it's really not expected and supported to have the
core_ops target remain on the target stack simultaneously and
below a process_stratum target (linux-nat.c, in your case).
I don't think it makes that much sense nowadays to have a
distinct core_stratum vs process_stratum. It core_ops was
a process_stratum, pushing linux-nat.c would auto discard
the core, as you can't have two targets of the same stratum
on the stack. The only main use for that stratum
nowadays is for find_core_target, I think.
> [...]
> (gdb) quit
> A debugging session is active.
> Inferior 1 [process 13887] will be killed.
> Quit anyway? (y or n) y
> inferior.c:362: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
>
> gdb/
> 2010-05-21 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> Forbid run with a core file loaded.
> * infcmd.c (run_command_1) <core_bfd>: New.
What about "attach"?
>
> gdb/testsuite/
> 2010-05-21 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> Forbid run with a core file loaded.
> * gdb.base/corefile.exp (load core again, start with core)
> (started with core): New tests.
>
> --- a/gdb/infcmd.c
> +++ b/gdb/infcmd.c
> @@ -483,6 +483,15 @@ run_command_1 (char *args, int from_tty, int tbreak_at_main)
>
> dont_repeat ();
>
> + if (core_bfd)
> + {
> + if (!from_tty
> + || query (_("Core file is already loaded. Unload it? ")))
> + core_file_command (NULL, from_tty);
> + if (core_bfd)
> + error (_("Core file not unloaded."));
> + }
> +
I wish this would query a target property instead of poking
core_bfd directly, but I don't see what. Several targets call
target_preopen to clean up the previous different target, which
does more cleanup than just getting rid of the core target, but
it looks a bit messy to harmonise this. So I'm fine with
going this route.
"is already loaded" sort of implies (to my ears) that you are
trying to load another core. "load a core --- what do yo mean
? I _already_ have one loaded."
Taking from attach_command, how about:
"A core file is being debugged. Unload it? "
Anyway, that's just a suggestion. Ignore that one if you
don't like it.
--
Pedro Alves