From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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 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, 08 Apr 2022 21:41:24 -0000 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.