Re: [patch] Forbid run with a core file loaded

[Pedro Alves <pedro at codesourcery dot com>]

On Sunday 23 May 2010 19:54:40, Jan Kratochvil wrote:
> On Fri, 21 May 2010 17:06:07 +0200, Pedro Alves wrote:
> > I don't think it makes that much sense nowadays to have a
> > distinct core_stratum vs process_stratum.
> 
> OK, removed core_stratum.

Thanks.

> @@ -194,6 +195,10 @@ inf_ptrace_attach (struct target_ops *ops, char *args, int from_tty)
>    if (pid == getpid ())                /* Trying to masturbate?  */
>      error (_("I refuse to debug myself!"));
>  
> +  /* target_pid_to_str already uses the target.  Clear possible core file with
> +     its process_stratum.  */
> +  pop_all_targets_above (ops->to_stratum - 1, 0);
> +

Unfortunately, this would break multiprocess.  For example, you may
be attaching to your second process (e.g., "start", "add-inferior",
"inferior 2", "attach $pid"), and the thread stratum needs to remain
pushed for the first inferior/process.

> +  /* Clear possible core file with its process_stratum.  */
> +  push_target (ops);
> +
>    pid = fork_inferior (exec_file, allargs, env, inf_ptrace_me, NULL,
>                        NULL, NULL);
>  
> -  push_target (ops);

This makes sense, as indeed fork_inferior touches the current
target, even today, but, can you check what happens if fork_inferior
throws an error?  I worry that if, for example, exec fails, we still
end up with the target pushed.  Probably not a big issue for linux-nat.c,
which since it support multi-process, handles being pushed with
inferior_ptid == null_ptid, but other ptrace targets don't.

> On Fri, 21 May 2010 17:02:31 +0200, Joel Brobecker wrote:
> > > +set test "start with core"
> > > +gdb_test_multiple "start" $test {
> > > +    -re {Core file is already loaded.  Unload it[?] [(]y or n[)] } {
> > > +   pass $test
> > > +    }
> > > +}
> > 
> > We should not use the "start" command in testcases, as it does not
> > work with remote targets. I'm afraid we're going to have to rely on
> > the run command instead.

There's some confusion here.  "start" doesn't work with "target remote",
just as much as "run" doesn't work.  In other words, if "run" would
work, so would "start", as the latter is just the former plus an
internal temporary breakpoint on `main'.

> OK, used runto_main now.  Attach test does not run with gdbserver the same way
> gdb.base/attach.exp does not.  Tested this testfile with runtest-gdbserver
> (only on localhost).

-- 
Pedro Alves