From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 56DE03858D37 for ; Thu, 1 Dec 2022 01:15:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56DE03858D37 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-oi1-x234.google.com with SMTP id v82so512601oib.4 for ; Wed, 30 Nov 2022 17:15:26 -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=t06z1gpVYduId42CrvlcS+n/RbcHxnk7l3vRSiTbiH8=; b=Ekvgs3y+CYv3mei5azEdpJxNd0ka1NA7ttodMUINh4W7ivlzTKlq0n2DikqaL3r08/ FNp43I8xf9nYUE+6vSUj3n1Efj5UPpzptn/2oErGls+7jm/vH8G0dgnzz7NklQFQ0KGU 3QqkSOrj7pMYkzKXRhpzvvVcntIJ6cMqRnW/VBpcTnkwVzmJED72ieYQfgj7auTReNBK D/l6YCm97xNWcelpkrvbITHaE0Rw8SIBO2wjm/hM8rwVbpQ91/8p4Pk6ccFZtFlWr5X1 X2U4Amal3p8WJCLG/sNd4YyrkXodx8+JZv/WaaK834MXhxph7K7ZVcGAwcEWjpqyLqLt q1HA== 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=t06z1gpVYduId42CrvlcS+n/RbcHxnk7l3vRSiTbiH8=; b=Sq+1mHmeXURVOUkJFr6J/V/8eveOgoyFn/AThv+XU6nxr6Ts0YxNtAR9kngA6jf5EE /mElmDiIbhnH7h4p1oKVOrn7vNgxsVjzM8Gv8LxsIaU/80BwrrW1mB2VHThFecU1z+uQ Bl22BSgW86hAsdVogbNJmDQYEhQ6oFuiYKpBjmXPtgbxBQuaUybCA5SoO2+TtBrc9DXd 6SqDFP0fVWt6DHmYqDXM8q0nIHUwQ/EfZSNaoimXSckDhggVpPpbhuBJgH9x/q+XK5AO U6TYycgPyvCCp9+8+pceaE2BFaUZs92Sf8jBXAXHcl3ZBR4ZCDcmXn8lb35ur0z1Gwnu w2FA== X-Gm-Message-State: ANoB5pk6oKdo8bi0rOdIjBuzv7GVGtXrgIm3F4DTkM0a5poeAgZSfKR1 57New8/dvRZf+/aUI2Kg8YFCpA== X-Google-Smtp-Source: AA0mqf7aweBD/XRhWKnrdrevWMSPZyrpTCK4p4LpbOOXrsPNTuP6B16k8hTxcFEWFE3nhxYuH+Fy3g== X-Received: by 2002:a54:408f:0:b0:359:33c2:e5d6 with SMTP id i15-20020a54408f000000b0035933c2e5d6mr33121174oii.174.1669857325636; Wed, 30 Nov 2022 17:15:25 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:fdf7:5a86:5f9a:55aa]) by smtp.gmail.com with ESMTPSA id w9-20020a9d4509000000b00661a16f14a1sm1567594ote.15.2022.11.30.17.15.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Nov 2022 17:15:24 -0800 (PST) References: <20221126020452.1686509-1-thiago.bauermann@linaro.org> <20221126020452.1686509-7-thiago.bauermann@linaro.org> <034a34c3-4c4b-2c90-9703-52c439c70164@arm.com> User-agent: mu4e 1.8.11; emacs 28.2 From: Thiago Jung Bauermann To: Luis Machado Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 6/6] gdb/aarch64: Detect vector length changes when debugging remotely In-reply-to: <034a34c3-4c4b-2c90-9703-52c439c70164@arm.com> Date: Thu, 01 Dec 2022 01:15:21 +0000 Message-ID: <87v8mvgc0m.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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 11/26/22 02:04, Thiago Jung Bauermann 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. > > debugging programs -> debugging programs remotely Indeed. Fixed. >> 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. >> To allow changing the architecture based on the expedited registers, add= a >> new gdbarch method to allow arch-specific code to make the adjustment. >> diff --git a/gdb/gdbarch-components.py b/gdb/gdbarch-components.py >> index 9b688998a7bd..fbb32c5e5853 100644 >> --- a/gdb/gdbarch-components.py >> +++ b/gdb/gdbarch-components.py >> @@ -2698,3 +2698,19 @@ Read core file mappings >> predefault=3D"default_read_core_file_mappings", >> invalid=3DFalse, >> ) >> + >> +Method( >> + comment=3D""" >> +An architecture may change based on the current contents of its registe= rs. >> +For instance, the length of the vector registers in AArch64's Scalable = Vector >> +Extension is given by the contents of the VL pseudo-register. > > VL -> VG Ok, changed. >> +This method allows an architecture to provide a new gdbarch correspondi= ng to >> +the registers in the given regcache. >> +""", >> + type=3D"struct gdbarch *", >> + name=3D"update_architecture", >> + params=3D[("const std::vector &", "regcache")], >> + predefault=3D"default_update_architecture", >> + invalid=3DFalse, >> +) >> @@ -14382,6 +14407,23 @@ remote_target::thread_info_to_thread_handle (= struct >> thread_info *tp) >> return priv->thread_handle; >> } >> +struct gdbarch * >> +remote_target::thread_architecture (ptid_t ptid) >> +{ >> + thread_info *thr =3D find_thread_ptid (this, ptid); >> + remote_thread_info *remote_thr =3D nullptr; >> + >> + if (thr !=3D nullptr) >> + remote_thr =3D get_remote_thread_info (thr); >> + >> + if (remote_thr =3D=3D nullptr || remote_thr->expedited_arch =3D=3D nu= llptr) >> + /* The default thread_architecture implementation is the one from >> + process_stratum_target. */ >> + return process_stratum_target::thread_architecture(ptid); >> + >> + return remote_thr->expedited_arch; >> +} >> + >> bool >> remote_target::can_async_p () >> { > > Just to confirm, as I don't exactly remember how this went. Is the case w= here we switch > threads during remote debugging covered in case we have threads with diff= erent vector > lengths? > > I seem to recall we'd call thread_architecture in those cases, but I don'= t know how the > expedited register comes into play for this case. Do we get expedited reg= isters for each > thread that has stopped? I thought this was fine because my limited understanding of the remote protocol was that whenever a thread stops, a T stop reply is sent with the expedited registers. However, when I tried testing this scenario it didn't work: I get a =E2=80=9CTruncated register 51 in remote 'g' packet=E2=80=9D error when the= main thread hits a breakpoint and I try to switch to another thread with a different vector length. It turns out that gdbserver only sends the T stop reply for the thread that hit the breakpoint. Thanks for spotting this problem. I will add a testcase to exercise this scenario and see if I can come up with a fix. > Otherwise LGTM. > > Reviewed-by: Luis Machado Thanks! --=20 Thiago