From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xEttJhKsUGKuNgAAWB0awg (envelope-from ) for ; Fri, 08 Apr 2022 17:41:38 -0400 Received: by simark.ca (Postfix, from userid 112) id 8AB501EFC5; Fri, 8 Apr 2022 17:41:38 -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 D7B071EDF0 for ; Fri, 8 Apr 2022 17:41:37 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 433A13857811 for ; Fri, 8 Apr 2022 21:41:37 +0000 (GMT) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by sourceware.org (Postfix) with ESMTPS id A0CFC3858D28 for ; Fri, 8 Apr 2022 21:41:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A0CFC3858D28 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-wm1-f50.google.com with SMTP id r64so6353774wmr.4 for ; Fri, 08 Apr 2022 14:41:22 -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=kZmNpb/kvXIQ6TDB7efkIjxaAz6TRsNZfibERw8JMR4=; b=j1kfoOy+InpTwk2n8d8cB3aSs3bRV7JCUSZMsG+dOtaymsVMRHuYWpuomgI/ZlpgMp SurJLovjmkCXOgu+I+VBU0Tnxi/9pU/OotVObI+G8u4MMe2D5Y7CUIRCwvxH6KqGZTfN HfMFZvZlscvhUTOgJkf5quRaoOl7o9/Z+oBLRmCsXLLuaPAIHaRfc9PR8qU79npBfK6J kaYdJdaoNeB3N+Ge8PnNtKCHcH0Zy7lJu+9qvyOUtOfh0koy4Zt6JiPCO+rLXGhMXOmB kwTNpBDYjnxN803iu8KxrgA3piWcaBjMIp19Jw0lVqoFgcvz923Rw6B7OUYxT/heqXLx uARA== X-Gm-Message-State: AOAM532xMQGVNnnbtX+YC7S7IOmk/DHU2PqbU3Y1lxbI9wdAqWWh2A6S W5HICvDiKbxVFuSNeuJcwp0= X-Google-Smtp-Source: ABdhPJykT3xP9ZovoQFWvYq0n/KnOOEDArOaD7nztx5H7TrTluq0ojQn0p0oB/37zHVEFEOenSmpqw== X-Received: by 2002:a05:600c:3d8d:b0:38c:82dc:cd58 with SMTP id bi13-20020a05600c3d8d00b0038c82dccd58mr18557951wmb.50.1649454081386; Fri, 08 Apr 2022 14:41:21 -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 o9-20020a056000010900b00206186ac25esm11935590wrx.12.2022.04.08.14.41.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Apr 2022 14:41:19 -0700 (PDT) Message-ID: <12dff0f1-86cf-6e73-e0bb-0e6a09ab5f83@palves.net> Date: Fri, 8 Apr 2022 22:41:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: RiscV GDB remote protocol seems to expect stop reply to change Hg in all-stop mode Content-Language: en-US To: "Denio, Mike" , "gdb@sourceware.org" References: From: Pedro Alves In-Reply-To: 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-04-08 16:36, Denio, Mike via Gdb wrote: > I noticed that in all stop mode, GDB expects the current Hg thread to be changed to the thread reported in the stop reply message, without sending an Hg command. This can most easily be seen by using the "i threads" command. GDB will read the registers of each (non-current) thread using 'Hg' / 'g', so it can display the PC location in the threads list. However, after a stop message, GDB appears to assume that the Hg thread is set to the current thread, even though it changed the Hg thread during 'i threads'. I could not find where this was documented. I could swear this was documented, but I can't actually find it either. This has "always" been this way, AFAIK. In GDB's remote_target::wait_as, you can see that GDB calls record_currthread to make the Hg thread match the event thread. In GDBserver, we have this, in prepare_resume_reply: /* This if (1) ought to be unnecessary. But remote_wait in GDB will claim this event belongs to inferior_ptid if we do not specify a thread, and there's no way for gdbserver to know what inferior_ptid is. */ if (1 || cs.general_thread != ptid) { int core = -1; /* In non-stop, don't change the general thread behind GDB's back. */ if (!non_stop) cs.general_thread = ptid; I actually remember running into this comment that if (1) when I started working in gdbserver, and I may have learned this from the code instead of from the manual. Non-stop was added later, and changing the current thread when an event is reported is just completely incompatible with the asynchronous way of non-stop RSP stop events, so I added that if (!non_stop). I guess I didn't realize back then that that should also be documented somewhere. If no one beats me to it, I'll clarify this in the manual when I have a chance. > > The 'fix' for me was to assume both Hg and Hc are auto-changed to whatever thread is reported in the stop reply when in all-stop mode. GDB only auto-changes the Hg thread, see record_currthread.