From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x29.google.com (mail-oa1-x29.google.com [IPv6:2001:4860:4864:20::29]) by sourceware.org (Postfix) with ESMTPS id 763AA38500B8 for ; Fri, 9 Dec 2022 02:20:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 763AA38500B8 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-142b72a728fso4085722fac.9 for ; Thu, 08 Dec 2022 18:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references:from:to:cc:subject:date :message-id:reply-to; bh=ok+abJmNqHGnq0wJ0cq9z3tAcesFMQv4fbSxYYftLIQ=; b=oNgsplOP6WtlmfpMwFVmP1Y2iMjFWZz85IHr6dM2+iAtbWcp4aIaS/bpJ2PosnSxbz kryTpbGRSk1nKlR7mFbbu3FNvMkLB4UL5HtsKzjlGiUm9d+AcXFsE/lHJypWlj+0ClHX bWXFnq66DGwtTujVdez3yoCdeSua46bCx+ZAigwH3fY6zScuz4nSZ24xYDN15umpxhQd BqWt9G79AQca+cOrDtxKA9L+gXNAjEBSDBY0hkfAEVGV9CvA8pEXe5Fc/OO+hA3PcJ+A y1GwxnZqry7g6B7rpTNaxouAqQrZu14C+jAZpoGMY0gSZdXfKm+WsAo2/BxfyXQqdoqZ 1OwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=ok+abJmNqHGnq0wJ0cq9z3tAcesFMQv4fbSxYYftLIQ=; b=vFrNYyWwhK7wLILTfKqfKYrcN4VWtLOmPFjYF0EVlcev3GqL8Evs/dU4xnD+6ob5Gh ZZLv+Wx9moHk9dUYlSixLrKc5/7sLwF4CXwlMepkaBf0Dv5UeHkyGHYUF/gemFKnRIR1 gbsupcgB8hHp5Rywx2BjiXTRMlVHmx9gbl3pD+fXsQpZAr66HJ6HzVQfxNnRfZD47kWg gRDVCCWssa+ztnC8xSKCWKVqNCe8KhesGuy7kz23ypfctcB8JVsetSkkVonAjXH7q18h f5ZWwN2gmPqLslwK8iNAjbQZji96XDG51ox0NO/wCW3PMGCpXGXMUrbb9vZRTEsX+Ep9 XQ4w== X-Gm-Message-State: ANoB5pmfy9/b1SQiNg0Jc2Cq6+Cmrw3nrWw5WCtjj7cX20S+KWFS7ON8 502xCtx7D82qCWBRTOSlzip9sQ== X-Google-Smtp-Source: AA0mqf49mWsfE70kD4p0NS746lMT2zuwCBHMrh77jsTLBfkvBo0VSX9w8wvDFOdrKn6haBx4iC8/Gw== X-Received: by 2002:a05:6870:bf0f:b0:144:374e:5c7f with SMTP id qh15-20020a056870bf0f00b00144374e5c7fmr1957151oab.53.1670552421752; Thu, 08 Dec 2022 18:20:21 -0800 (PST) Received: from localhost ([2804:14c:101:ace1:1bb1:4525:9b2d:d20d]) by smtp.gmail.com with ESMTPSA id b8-20020a056870390800b001435fe636f2sm207663oap.53.2022.12.08.18.20.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 18:20:21 -0800 (PST) References: <20221126020452.1686509-1-thiago.bauermann@linaro.org> <20221126020452.1686509-7-thiago.bauermann@linaro.org> <87edtdiijv.fsf@linaro.org> <0605407e-a9bf-06c1-c513-e6202181a51f@arm.com> <559069a3-f3ce-2059-bf4a-44add43979f7@simark.ca> <013ebc82-c7de-a455-4f07-ca9c1c02170c@arm.com> User-agent: mu4e 1.8.11; emacs 28.2 From: Thiago Jung Bauermann To: Luis Machado Cc: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH v2 6/6] gdb/aarch64: Detect vector length changes when debugging remotely In-reply-to: <013ebc82-c7de-a455-4f07-ca9c1c02170c@arm.com> Date: Fri, 09 Dec 2022 02:20:18 +0000 Message-ID: <87o7sd9v31.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Luis Machado writes: > On 12/7/22 19:25, Simon Marchi wrote: >> Reading this, I thought of another potential problem with using >> expedited registers to communicate the architectures change. When using >> the non-stop version of the remote protocol, we will have a stop reply >> for each thread that stops, so that's fine, we can infer each thread's >> tdesc. But with the all-stop variant of the protocol, you only get a >> stop reply for one thread, for a given stop. > > I wasn't sure about this case, so I mentioned it in the first reply to > patch 6/6. Isn't it possible to send back information about all the > threads that have stopped in all-stop mode? I think it could be done by adding the extra information in the XML of the qXfer:threads:read reply as Simon suggested here. I thought about adding the expedited registers for each thread to fix this case, but as long as we are making changes to the remote protocol, Simon's idea is cleaner and more general. >> For instance, imagine you have two threads, thread 1 hits a breakpoint. >> GDB gets a stop reply for thread 1, and thread 2 is just considered stop >> because we're using the all-stop remote protocol. If we need to read >> thread 2's registers, we would need to know its tdesc. Its vg may have >> changed since last time, or it might be the first time we learned about >> it. In that case, I don't think we have a way out of adding some mean >> for gdbserver to tell gdb which tdesc applies to that thread. >> If it's the case, that we need to extend the RSP to allow fetching >> per-thread tdesc, here's the idea I had in mind for a while, to avoid >> adding too much overhead. Stop replies and the qXfer:threads:read reply >> could include a per-thread tdesc identifier. That tdesc identifier >> would be something short, either an incrementing number, or some kind of >> hash of the tdesc. It would be something opaque chosen by the stub. A >> new packet would be introduced to allow GDB to request the XML given >> that ID. On the GDB side, GDB would request the XML when encountering a >> tdesc ID it doesn't know about, and then cache the result. The >> additional overhead would be: > > The aarch64 port uses feature hashes for the target descriptions. We > could leverage that, but we would need to keep the hash stable so > older gdb's that don't know about certain features don't break/get > confused. IIUC the tdesc ids are defined by gdbserver and are opaque to GDB, and also they are only meaningful within a single connection, so they don't need to be stable. Because of that, I think small integers are preferable to hashes because they are shorter so it's less data to push through the wire. >> - fetching each XML tdesc once, that seems inevitable (we just don't >> want to fetch the same XML tdesc over and over) >> - a few characters more in stop replies and qXfer:threads:read replies >> I believe this could be implemented in a backwards compatible way >> without even adding a new qSupported feature. XML is extensible by >> nature. And stop replies are too. The T stop reply doc says: >> Otherwise, GDB should ignore this =E2=80=98n:r=E2=80=99 pair and go o= n to the next; >> this allows us to extend the protocol in the future. >> So in theory we could add a `tdesc-id:1234` field without breaking old >> GDBs. However, those old GDBs would break when trying to read registers >> of threads with unexpected SVE lengths. > > It sounds like a good approach to me, and slightly better than using > the expedited registers. I agree. Thanks Simon for this idea and for detailing it! I'll take a stab at implementing it for v3. > It would be nice if we could minimize the amount of tdesc-id entries > for all the threads, if they're mostly the same. > > The most obvious case is having hundreds of threads that all have the > same tdesc-id. It wouldn't be nice to duplicate all that data. gdbserver can assign the same id for identical tdescs, so I think this will happen naturally. > Originally we discussed a packet to ask the remote if the target > description had changed. If nothing's changed, it is a quick reply. > > I suppose we could have something similar to that here as well, to > optimize things, that is, don't return data if nothing's changed. Yes, if it happens that GDB needs to fetch registers without having received a tdesc-updating T stop reply or qXfer:threads:read reply then this is a good solution. --=20 Thiago