From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17730 invoked by alias); 23 May 2010 21:08:56 -0000 Received: (qmail 17722 invoked by uid 22791); 23 May 2010 21:08:56 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 23 May 2010 21:08:50 +0000 Received: (qmail 17758 invoked from network); 23 May 2010 21:08:48 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 May 2010 21:08:48 -0000 From: Pedro Alves To: Jan Kratochvil Subject: Re: [patch] Forbid run with a core file loaded Date: Sun, 23 May 2010 21:16:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-21-generic; KDE/4.3.2; x86_64; ; ) Cc: Mark Kettenis , Joel Brobecker , gdb-patches@sourceware.org References: <20100523185440.GA12068@host0.dyn.jankratochvil.net> In-Reply-To: <20100523185440.GA12068@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005232208.44968.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00542.txt.bz2 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