From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) by sourceware.org (Postfix) with ESMTPS id 581C63858D37 for ; Thu, 1 Dec 2022 03:16:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 581C63858D37 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-x30.google.com with SMTP id 586e51a60fabf-142306beb9aso733045fac.11 for ; Wed, 30 Nov 2022 19:16:55 -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=tCFqK7rocFMGB8SlvKnC6EuENIOsAk/R0t9s+M94CWk=; b=LZBbAHwTopr2FHebXIRWwlaomudNwVTg35dMFfCNcfF8rnjWjXfAzuh8N6DhiymG9E 9p9JoCGNf3tbNgQd2te9Ieqnzy9AvC4n2kOJ8cyZ5Wc9jJ9D2WHxuNtpZus+LaC/KBD2 cszb8sufMu6VlbYrooqeOLKSRzD+XinTiAuanI/oF78x5G2Qr7xKFJLMy0AJc28+KYjC eewVk9s++n6ZO6KGwO/XYrqdnwnsoVfaXEzRFsXCtQ3FvK+mlT7rCMqkr/JGYuWw0a99 ad16TP67fMdxpanRhbnkG19nVEjHNWhQqEJ5x3EYcpCxLtrf3ulo+I27ZwPCDNg7Rshv oGmg== 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=tCFqK7rocFMGB8SlvKnC6EuENIOsAk/R0t9s+M94CWk=; b=iLrOBgDZRbDDzRG+qxVLbq5jGCQtnVebsjlB1ipFfA7BCE9pT1C9hZzVMzLnV4VbTY d+hlEMHQ0o43cDfotN4DbYOw2Cz5e8DR5Sn0ZhsjptAWkevW5RPemwR0fyIFG7r0jtbG eYAPj2udujxPMBbEsw2k+bGee6kCzUaj+aRZsBGlPUunnRDcDDDOHXll7+47/m6T3zLE J5XExAj+0wi5JXBw0JfTL/Kq2fp1ji6ZyfFnb3+TgRO3n3tPDhFBQpCkE7My/qEUMiZL NYDOLpSv9obZSkiz3Zrx+t4wW8OeE+pPS30q4zywx/2xqyc1lXJfyAAwhTOvptUXwPHr NBkA== X-Gm-Message-State: ANoB5pkiMmUHkvVoLS8Yum+GZOywQDncUV0tqZzQfFsRbOBRo3kjZglH /Yn4eL7REZYipm1oaZ3opvw5GIn+SwO3Qg== X-Google-Smtp-Source: AA0mqf6ovePhZNNW3NyIxaPwfM5UqxA+1HZjwx8akN1BWX0Gm93a6CGd7Fhk8TXHJMIG9AkyYkks2g== X-Received: by 2002:a05:6870:ac0e:b0:13c:91e0:5b25 with SMTP id kw14-20020a056870ac0e00b0013c91e05b25mr25496273oab.226.1669864614483; Wed, 30 Nov 2022 19:16:54 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:fdf7:5a86:5f9a:55aa]) by smtp.gmail.com with ESMTPSA id n24-20020a4ae1d8000000b0049b17794d19sm1397931oot.20.2022.11.30.19.16.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Nov 2022 19:16:53 -0800 (PST) References: <20221126020452.1686509-1-thiago.bauermann@linaro.org> <20221126020452.1686509-7-thiago.bauermann@linaro.org> <5d3ca3ed-df52-444e-1652-99b149137707@simark.ca> User-agent: mu4e 1.8.11; emacs 28.2 From: Thiago Jung Bauermann To: Simon Marchi Cc: gdb-patches@sourceware.org, Luis Machado Subject: Re: [PATCH v2 6/6] gdb/aarch64: Detect vector length changes when debugging remotely In-reply-to: <5d3ca3ed-df52-444e-1652-99b149137707@simark.ca> Date: Thu, 01 Dec 2022 03:16:51 +0000 Message-ID: <87r0xjg6e4.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.2 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: Simon Marchi writes: > On 11/25/22 21:04, Thiago Jung Bauermann via Gdb-patches wrote: >> If the remote target provides an expedited VG register, use it to update >> the thread's gdbarch. This allows debugging programs that change their S= VE >> vector length during runtime. >>=20 >> This is accomplished by implementing the thread_architecture method in >> remote_target, which returns the gdbarch corresponding to the expedited >> registers provided by the last stop reply. >>=20 >> To allow changing the architecture based on the expedited registers, add= a >> new gdbarch method to allow arch-specific code to make the adjustment. > > I get this when applying, can you address that? > > Applying: gdb/aarch64: Detect vector length changes when debugging remote= ly > .git/rebase-apply/patch:164: indent with spaces. > "gdbarch_dump: update_architecture =3D <%s>\n", > .git/rebase-apply/patch:165: indent with spaces. > host_address_to_string (gdbarch->update_architectu= re)); > .git/rebase-apply/patch:186: indent with spaces. > gdbarch_update_architecture_ftype updat= e_architecture) > warning: 3 lines add whitespace errors. This is because gdbarch.py generates these lines in gdbarch.c with spaces-only indentation. I will send a separate patch to fix it. > I think the idea makes sense. Short of adding a packet for "get thread > architecture" or extending the stop reply format to add a note about a > thread having a special tdesc, I don't see another way to do this. We I guess we could define such a packet, but this approach is indeed simpler. > can't read the vq register using 'g', because to interpret the 'g' > result, we need to know the full architecture. We wouldn't know for > sure the offset of vq in the reply. By using expedited registers, we > just need to make sure vq's register number is stable. I guess that is > the case? The register number is determined by the function aarch64_create_target_description. If SVE is supported, VG will always have the register number 85. If not, then AFAIU the register number will be unused (since the PAuth, MTE and TLS features only have a few registers). But it could potentially be used by another feature in the future... Do we have to reserve the number 85 for the VG pseudo-register? >> @@ -8068,6 +8078,21 @@ remote_target::process_stop_reply (struct stop_re= ply *stop_reply, >> /* Expedited registers. */ >> if (!stop_reply->regcache.empty ()) >> { >> + /* If GDB already knows about this thread, we can give the >> + architecture-specific code a chance to update the gdbarch based on >> + the expedited registers. */ >> + if (find_thread_ptid (this, ptid) !=3D nullptr) >> + { >> + stop_reply->arch =3D gdbarch_update_architecture (stop_reply->ar= ch, >> + stop_reply->regcache); >> + >> + /* Save stop_reply->arch so that it can be returned by the >> + thread_architecture method. */ >> + remote_thread_info *remote_thr =3D get_remote_thread_info (this, >> + ptid); >> + remote_thr->expedited_arch =3D stop_reply->arch; >> + } >> + >> struct regcache *regcache >> =3D get_thread_arch_regcache (this, ptid, stop_reply->arch); > > > What happens with threads that are not yet known? Imagine the process > starts with SVE =3D=3D X, the main threads spawns a worker thread, the > worker thread updates its SVE to Y, and the worker thread hits a > breakpoint. This is the first time we hear about that worker thread. I tested this scenario and... it sort of works, but not quite. When the unknown thread hits the breakpoint, gdbserver sends a T stop reply packet with the new VG value in the expedited registers. It will be the first time we hear about that worker thread, but at the same time we will also learn about the value of its VG pseudo-register. So GDB reports the breakpoint hit event and gets to the prompt as expected. You can even print the new value of the VG pseudo-register, or any other expedited register such as PC or SP. It's only when you try to print the value of a non-expedited register that you get an error indicating that GDB and gdbserver don't agree on the size of the SVE registers (=E2=80=9CTruncated register 51 in remote 'g' packet=E2=80=9D). > If we don't do a "gdbarch_update_architecture" for it and save it > somewhere, we'll never set the gdbarch with SVE =3D=3D Y, will we? We do that in remote_target::process_stop_reply, and I was under the impression that it happened early enough for GDB to have the correct gdbarch available when it needs it, but unfortunately that's not the case. I will add a testcase exercising this issue and see if I can find a solution. Thank you for spotting it. --=20 Thiago