From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30148 invoked by alias); 17 Mar 2010 15:22:09 -0000 Received: (qmail 30132 invoked by uid 22791); 17 Mar 2010 15:22:08 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 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; Wed, 17 Mar 2010 15:22:04 +0000 Received: (qmail 31797 invoked from network); 17 Mar 2010 15:22:02 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Mar 2010 15:22:02 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Marc Khouzam Subject: Re: [PATCH] No resuming while tfinding Date: Wed, 17 Mar 2010 15:22:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; ) Cc: Stan Shebs References: <4BA0377C.1040000@codesourcery.com> In-Reply-To: <4BA0377C.1040000@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201003171521.59901.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-03/txt/msg00620.txt.bz2 On Wednesday 17 March 2010 01:59:24, Stan Shebs wrote: > So I propose that we make an executive decision to disable all the > resumption commands while in tfind mode. Does this make sense to everyone? I object to not making this change. :-) We should look at tfind mode as sort of a different target. It's is kind of similar to debugging a core dump while still connecting to a live target. (yay, GDB has gone multi-target already :-D) Execution commands aren't allowed when debugging a core dump either. At most, some could map some of those commands to browsing through the traceframes, like "stepi" (heuristically) following while-stepping traceframes, but, never to running the live target. Execution commands are prohibited when debugging core dumps by having the core_ops target return false to target_has_execution, instead of having checks in every command though. We could try just installing a remote.c:remote_has_execution callback that returns false when in tfind mode, but, it would automatically prohibit e.g., "kill", "attach", "detach", "run", etc. as well, which is not clear we do want to prohibit those in tfind mode, and the resulting "The program is not being run." error looks confusing in that case. We could always tweak ERROR_NO_INFERIOR though. > 2010-03-16 Stan Shebs > > * infcall.c: Include tracepoint.h. > (call_function_by_hand): Disallow calls in tfind mode. > * infcmd.c (ensure_not_tfind_mode): New function. > (continue_1): Call it. > (step_1) Ditto. > (jump_command): Ditto. > (signal_command): Ditto. > (until_command): Ditto. > (finish_command): Ditto. This misses the "until" command, in breakpoint.c. > *** infcmd.c 16 Feb 2010 21:18:46 -0000 1.259 > --- infcmd.c 17 Mar 2010 01:34:00 -0000 > *************** > *** 56,61 **** > --- 56,62 ---- > #include "inline-frame.h" > > extern void disconnect_or_stop_tracing (int from_tty); > + extern int get_traceframe_number (void); This is unnecessary, get_traceframe_number is declared in tracepoint.h. The disconnect_or_stop_tracing declaration shown above could use moving there as well... -- Pedro Alves