From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) by sourceware.org (Postfix) with ESMTPS id 9885E385803E for ; Fri, 6 May 2022 17:45:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9885E385803E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-vs1-xe35.google.com with SMTP id y74so7877258vsy.7 for ; Fri, 06 May 2022 10:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BM+/oKGsqcrUpfbWwZyUyU3Y5HwusAUlWIU9acKYg5Y=; b=VnVGp/8Fsy6m886YNEQTdUsGlHDB8dukrKv/EBq8RKPhEIxtTkhCKQzHk8LDa0Aa0p bCRpJz+PHkAvCllsYuL+0wKOsMuzGn55mhS/rcDzY0pmyNwCJ2e+nvw2pCa4ljda7SFI gtKrfOO+77HB6ygcLLdZqwxkG0FAIEfr5pfdGFtxjzE6IYveZ6+XvWjtWD+Gefg7a1yb GpzQq97A6vcO6VNlwevQB668STkIMDMEoDVB9AYztFQDEA/1Y9dpg7DGw2LKpehOrGIN Ho1m1JarqpTQFmeHfWeRPrnWXaQBvy+SKBADjupFTggc+MljKu6Bwi1yg9oGvqFU0bxc z3zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BM+/oKGsqcrUpfbWwZyUyU3Y5HwusAUlWIU9acKYg5Y=; b=J5PzBNhb8EbnY/lChgME0Iykp4JmiHu212vgCnbrzj1zUf7SuYdU7VqqhWucYXELhW nZ+JFXR53dCBKl5ot8c1tg/DNxvv0mjRVaDyLXZPiGB2Hv/uXMdvwv1Xq70K+D9huMQr xncieLPMjt/TJZziHYK7kyOmvlr8nFo+4ngUF3t9oWo/O2tw5SnJ57jed21n8StgO1PY lZc662r1IKtUjr8hPYUpyz8n54Aexz1tyilcUOqBdX5bBzXUM6Ij8Hh9qZaob4KOHFtB PZM2KsVWjpaLP46MOSVxRcLkARF3unEaZ4kdrHHxXevN1YlNjIj4qtA3bf2xwkyOfEJH wzzQ== X-Gm-Message-State: AOAM532dgeJZvmQbEo7RDyN8tGF2zAM0MCafKZGvfFUF6o1vGv+9x/ws UB4C3DDimbZy3Wqp/R+xmJx/HQ4bex+IHEdfmfg7qfOBNzM= X-Google-Smtp-Source: ABdhPJw1lnouxnJszQGFYzcAFDeO4ligYe+6foXDZ+aP6vQJ4sGPKS2fZEznAHDgpbb88F4tQTKK1PzbQzRyQEfwhIo= X-Received: by 2002:a67:df98:0:b0:320:8446:7c6d with SMTP id x24-20020a67df98000000b0032084467c6dmr1442840vsk.16.1651859157887; Fri, 06 May 2022 10:45:57 -0700 (PDT) MIME-Version: 1.0 References: <87h764mk3j.fsf@redhat.com> In-Reply-To: <87h764mk3j.fsf@redhat.com> From: Tim Newsome Date: Fri, 6 May 2022 10:45:47 -0700 Message-ID: Subject: Re: gdb doesn't notice when a target resumes To: Andrew Burgess Cc: gdb X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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, 06 May 2022 17:46:00 -0000 Thanks, Andrew. That's pretty much my understanding too. In an ideal world gdb would have full control of the hardware, but that's unfortunately not the world we live in. Tim On Thu, May 5, 2022 at 1:58 AM Andrew Burgess wrote: > Tim Newsome writes: > > > In a setup like this: > > gdb --- OpenOCD --- hardware target > > > > I can download a program, debug, everything is fine. Let's say we're > halted > > somewhere. > > Now something happens that causes the hardware target to be running again > > and no longer halted. OpenOCD notices quickly because it polls the > target. > > But gdb doesn't ever notice that the target was resumed. There doesn't > > appear to be a notification packet > > < > https://sourceware.org/gdb/onlinedocs/gdb/Notification-Packets.html#Notification-Packets > > > > for > > OpenOCD to even communicate to gdb that the target has resumed. > > > > Am I missing something? Have people attempted to tackle this problem? > > The following is my understanding, others might have a better > understanding that contradicts what I say here. > > GDB expects to be the one driving the state of the target. It's not > expected that the target will just resume execution without GDB being > the one to set the target resumed. > > And that makes sense I think. GDB is primarily a debugger. If, as a > user, I stop the target in order to examine the state, and the hardware > suddenly resumes execution, that's a pretty poor user experience I > think. > > Depending on what the "something" is that sets the target running, you > might have more luck if that "something" could instead tell GDB to > resume the target. > > Otherwise you'd need to change GDB I think. Maybe non-stop mode could > support the concept of the targtet asynchronously resuming... but I > suspect it would not be a trivial addition. > > Thanks, > Andrew > >