From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2985 invoked by alias); 27 Feb 2008 22:00:26 -0000 Received: (qmail 2976 invoked by uid 22791); 27 Feb 2008 22:00:25 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog13.obsmtp.com (HELO s200aog13.obsmtp.com) (207.126.144.127) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Feb 2008 21:59:57 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Wed, 27 Feb 2008 21:59:55 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C929BDA66 for ; Wed, 27 Feb 2008 21:59:54 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6CB224C23C for ; Wed, 27 Feb 2008 21:59:54 +0000 (GMT) Received: from [164.129.14.85] (bri1017.bri.st.com [164.129.14.85]) by mail1.bri.st.com (MOS 3.7.5a-GA) with ESMTP id CJU33617 (AUTH antony); Wed, 27 Feb 2008 21:59:53 GMT Message-ID: <47C5DD59.5090608@st.com> Date: Wed, 27 Feb 2008 22:12:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Any solution to not being able to interrupt step in GDB ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00234.txt.bz2 I am currently using a version of GDB 6.6 (utilising our own remote target interface) and I am trying to come up with a solution to the problem we are seeing with the "step" command. The problem is that GDB is not making it easy :-) for me to interrupt the target when a "step" command has been issued on a statement of the following form: while (okay) continue; (where okay is a volatile that will be changed by an interrupt handler). Please note that the above example is an illustration of a general problem we encounter when debugging real-time multi-threaded embedded applications with pre-emptive scheduling and interrupts. GDB attempts to step the statement but the PC never falls outside the bounds of the statement address range and so GDB is forever performing a single instruction step. As a result I can only interrupt the "step" command when I press Ctrl-C while GDB executing target_wait(). If Ctrl-C is pressed outside of target_wait() (which in my implementation provides its own SIGINT handler), then GDB does not notice the event, as it is stuck in the following loop in wait_for_inferior() because ecs->wait_some_more is always TRUE: while (1) { if (deprecated_target_wait_hook) ecs->ptid = deprecated_target_wait_hook (ecs->waiton_ptid, ecs->wp); else ecs->ptid = target_wait (ecs->waiton_ptid, ecs->wp); /* Now figure out what to do with the result of the result. */ handle_inferior_event (ecs); if (!ecs->wait_some_more) break; } This means that the user has to continually press Ctrl-C in the hope of hitting the sweet spot. Is there any clean solution I can use which allows me to break out this loop if there is a pending SIGINT event waiting to be processed ? There seems a be a need for a way to "stop stepping" when Ctrl-C is pressed. One thought I have is to fake a target SIGINT signal by checking for a pending SIGINT event after returning from target_wait() and modifying ecs before calling handle_inferior_event(). Of course the same issue arises when using the MI interface (with, for example, Eclipse) but is worse since only a single stop request is issued. [ I have seen that the subject has been raised here: http://sourceware.org/ml/gdb/2007-03/msg00228.html but this did not seem to end with a solution. ] Any advice would be appreciated. Cheers, Antony.