From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) by sourceware.org (Postfix) with ESMTPS id E1178385E009 for ; Fri, 27 Mar 2020 18:27:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E1178385E009 Received: by mail-qv1-xf32.google.com with SMTP id n1so5399160qvz.4 for ; Fri, 27 Mar 2020 11:27:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+c1dRggLO+0pT/Q07TxV7c7u8kbc23HiJh440ZrH93E=; b=CSS8jcCe4zXbQNX/IlLfk3JJ14mDjHV7w4NftA6jKgwN9eIE7f//mc5MxfgvjEW336 3Dgm5ctm2jYEPYyU/G4cqnXpyqS4SZfJqZuUe1HcSOGtOs3WjsFjYrzxCfJPpDfaOVWs PcYXwLVte7aHDO7NHa0tRrnvd0/2iGFIQwz8oZLadITZzg6xJZ0WlVjssSVLAtRUamlr OH778xdVOBcfpGG/ttUqsrhH46NNQa+VS/6YOAa1siB1BxRFV3uhogeVgV6BMWdQ09lu VdBq1JUJyrEia9paZcXkdkRFvfUt4/D6QVgJwY/kUpXw6zoCvPBLAPjxSSVMu9Ifp2Gy 7EPA== X-Gm-Message-State: ANhLgQ1ocHNPXS3x6A/bb/NrvkQMdP78IL9u/fofbHMTDGHZfFzcGjow YcLG0cxdBQNHaKtuZz0DUPnuoYanRmw= X-Google-Smtp-Source: ADFU+vsiEOnEGV49t/3hMkzU9moxt1TXSc/Mmxyg15DpKIsb3zNr1OtGCDgFib8Znbmi/v9ttQ22dQ== X-Received: by 2002:a0c:edca:: with SMTP id i10mr580051qvr.130.1585333635918; Fri, 27 Mar 2020 11:27:15 -0700 (PDT) Received: from [192.168.0.185] ([191.34.83.48]) by smtp.gmail.com with ESMTPSA id f201sm4167167qke.119.2020.03.27.11.27.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Mar 2020 11:27:15 -0700 (PDT) Subject: Re: How to support interrupting a single step To: Torsten@Robitzki.de Cc: gdb@sourceware.org References: <0F5C3BB8-0274-4BAD-B92B-E0BB00217F55@Robitzki.de> <66219d95-9f03-7e83-7245-a9fecf670687@linaro.org> From: Luis Machado Message-ID: Date: Fri, 27 Mar 2020 15:27:11 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_LOTSOFHASH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 18:27:18 -0000 On 3/27/20 2:15 PM, Torsten@Robitzki.de wrote: > Hi Luis, > > I’m sorry, for the very late reply! > >> Am 18.10.2019 um 15:08 schrieb Luis Machado : >> >> The behavior of GDB when dealing with a tight/endless loop is known. See https://sourceware.org/bugzilla/show_bug.cgi?id=21221. > > that Bug describes behavior, that a tide loops can’t be jumped over. In my case, I try to interrupt that scenario. So running the binary, till that loop. Interrupt execution and finding the program counter in that loop. Then single stepping over the loop (either ’s’ or ’n’). Then gdb does not break on the next execution of the loop and I’m unable to break into the debugger again. ctrl-c simply does nothing and I have to kill the debug server, so that the lost connection to the debug server gives me the prompt back. > > Debugging the packages send and received, I find following: > > ^C > > 00d0030020276f0200b86a0200008c0021d0030020000000000000000000000000000000000000000000000000 > remote_pass_ctrlc called > remote_interrupt called > Sending packet: $s#73...Packet received: T05hwbreak;thread:0000DEAD; > Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200ba6a020000980021d0030020000000000000000000000000000000000000000000000000 > Sending packet: $s#73...^Cremote_pass_ctrlc called > remote_interrupt called > Packet received: T05hwbreak;thread:0000DEAD; > Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200bc6a020000000021d0030020000000000000000000000000000000000000000000000000 > Sending packet: $s#73...Packet received: T05hwbreak;thread:0000DEAD; > Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200be6a020000000021d0030020000000000000000000000000000000000000000000000000 > > I would expect that once GDB recognizes, that I want to interrupt execution, it would stop sending ’s’ and ‚g‘ packages. > GDB did recognize that you wanted to interrupt the remote and did send the right bytes to tell the remote to interrupt. I think what we're missing here is telling GDB your program stopped due to a SIGINT (GDB_SIGNAL_INT). This is what i see when interrupting a remote on my local machine. Notice the signal sent is 02 and not 05 (SIGTRAP). Sending packet: $vCont;s:p4e71.4e71;c:p4e71.-1#67...infrun: prepare_to_wait remote_pass_ctrlc called remote_interrupt called Packet received: T0206:50e2ffffff7f0000;07:50e2ffffff7f0000;10:1046555555550000;thread:p4e71.4e71;core:1; infrun: target_wait (-1.0.0, status) = infrun: 20081.20081.0 [Thread 20081.20081], infrun: status->kind = stopped, signal = GDB_SIGNAL_INT infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x555555554610 infrun: random signal (GDB_SIGNAL_INT) infrun: stop_waiting Sending packet: $z0,7ffff7a22c20,1#c3...Packet received: OK Sending packet: $z0,7ffff7b18bc3,1#fc...Packet received: OK Sending packet: $z0,7ffff7a22c93,1#cd...Packet received: OK Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l\n\n\n Program received signal SIGINT, Interrupt. So it seems your debugging stub needs to reply with SIGINT (interrupted) as opposed to SIGTRAP (meaning your program has concluded a single-step). Let me know if that fix what you're seeing.