From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0jnMHgzSNGIHHQAAWB0awg (envelope-from ) for ; Fri, 18 Mar 2022 14:40:12 -0400 Received: by simark.ca (Postfix, from userid 112) id 694B31F3CC; Fri, 18 Mar 2022 14:40:12 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C9A201EDF0 for ; Fri, 18 Mar 2022 14:40:11 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 33D1E3889809 for ; Fri, 18 Mar 2022 18:40:11 +0000 (GMT) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by sourceware.org (Postfix) with ESMTPS id 66DD6388451F for ; Fri, 18 Mar 2022 18:39:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 66DD6388451F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f49.google.com with SMTP id p9so12801737wra.12 for ; Fri, 18 Mar 2022 11:39:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=FRbXKpmx674k+HCZDzIWurLfstraxeGTrE1n66Uq+Wc=; b=4v81Ocv522lKMyh5C7rYUkd0mRlxxMIxoGP0ay8Y+62fYZqVZkOrhVAXekT1H/Lj8d os8LAChEehiQxRTiePotKHSWSlvsqkuozXLI6kMT5F4DDl0PYFVdoQ4CCw8Qi3ZDXuq/ hQkRjB+FJ8U2PBHARLWw2QNrIPxtDeyxZEAwKAOeR5/nsUzO82oRWBvLPUaxDaFwrGk+ iAJbbl9V2W/NWYZv2a8socEx0Fe8GUYh1nNNjTg4Ud5fkzEzYCsAfICBaKKGF5mNOO1C XxwHg8aHYeqNSijxn0xhzIASMJqqjj+48bGRhWoBXqEwHLj8peT7s+te0j/g9KXwB3Gz WBsA== X-Gm-Message-State: AOAM533gDIXYnv2oQ4i77Xe/e7T35hao5ocuOANsFvJQhQerk3RuibNa 9QSBJBRIyUofBB9rFZ9m8O2GUK8CR6Q= X-Google-Smtp-Source: ABdhPJwEt6hDiIa5ho96Af9NtAvpvo4W1i9s8jeIANcSJ9NNAXbwTioBB4tePYav64QDh+iA/j7y+Q== X-Received: by 2002:adf:eec2:0:b0:203:f121:2994 with SMTP id a2-20020adfeec2000000b00203f1212994mr5736239wrp.250.1647628795397; Fri, 18 Mar 2022 11:39:55 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id g10-20020adfe40a000000b00203eb3551f0sm5797146wrm.117.2022.03.18.11.39.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Mar 2022 11:39:54 -0700 (PDT) Message-ID: <61607c11-7acc-65d3-a82a-09981fed8315@palves.net> Date: Fri, 18 Mar 2022 18:39:53 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Step causes GDB to spin in infinite loop when PC doesn't change Content-Language: en-US To: "Denio, Mike" , Luis Machado , "gdb@sourceware.org" References: <43b85f60a2074311b5dcac347e9a68d2@ti.com> From: Pedro Alves In-Reply-To: <43b85f60a2074311b5dcac347e9a68d2@ti.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2022-03-18 17:57, Denio, Mike via Gdb wrote: > >>>>> > I recall we used to have some issues like that, where GDB wouldn't stop > stepping and would give you enough time to ctrl-C your way out of it, > but they were fixed as far as I recall. > > Are you using non-stop mode with synchronous commands? You might want to > try sending asynchronous commands (passing &), that way GDB will give > you the prompt instantly and you will have full control again. You can > then issue an interruption (interrupt -a) to stop everything. > <<<< > > Again, its not so much "what is the right command to use?" as it is "what happens if the user sends the wrong command?". > > I'm still new to this, but my interpretation of "step" was "step until the high level language instruction is complete, even if its multiple opcodes". This makes sense to me, to step over C instructions or multi opcode pseudo ops. The interpretation of "step" that makes less sense to me is "keep calling step until the PC changes", because if the PC didn't change after the first step, why would it ever change? "step" is defined as (gdb) help step Step program until it reaches a different source line. If the program has a loop that never reaches a different line, GDB will happily continue stepping. Nothing wrong with that. Could be spinlock, for example, waiting on some external condition, interrupt, whatever. Now, if Ctrl-C doesn't work, then that's a bug somewhere.