From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by sourceware.org (Postfix) with ESMTPS id 8E186384F494 for ; Mon, 5 Dec 2022 22:37:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E186384F494 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-x232.google.com with SMTP id v82so14776361oib.4 for ; Mon, 05 Dec 2022 14:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=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=iIda7KK15wUJZLFIvLssL5U57PxMIfceugcIw/0xjJs=; b=kBEEDnzr+LOxUSk6yX8n/fj1J/U5LfxYRSOhbtfC2L05D4HeLH+wg9pt1fdgFtC+OP q5xUVSEJ+vqeV7XplNr5jQBxAi00sGxKxnSeWJRLBCJPqGXmpFzTIE3aJXZC7bMKn0SE MmKa7qyrYELdHunPOkhD85rII2e2vXqrQPbt4P13U95jxlYvbh5KG+pSjO/R0TsoWZpA dHjQ0pV0AYPQGd10sjSsNrTf05nXBiFyD8uRK55b8vAmz4NlOCVlXhV3nTzFr5rVk1yg iM73CBxm2U7VD7LLKN1H/Wc1M57q4ozzMekE32n0nKPyuaAtLzZ09G2cU2bX0kGZXgKG 3F0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=iIda7KK15wUJZLFIvLssL5U57PxMIfceugcIw/0xjJs=; b=7STtSb/CKdeAS/BSO5qu/HV5X+DIKUXgPRRlKO7rDHmqSiIP20pzPk4V+NwoWdMm6S ChhhB0tl+d0c5hMF24WmA9ZFCmJi7DoNzOuydhW3RukRJWrtQkHawqE5rz2o9ezM3mD5 mR0BwmIKB+lkEyji/aVGbEmZwhna6X8VfNmZcS68BxCZJPBN5CPvQ8ImJWEyhxaFnxpY 1mEc1E66Il9W0oe0IJ3zlzEsKV7d9v1ugFZCqDeUD4omTiuXRo1GSlKZKWGwgyYlN2XU yuSaKGH7y+TIZB8A90CbEBDGDxVl/aBdaDDT7caiASG+z5IKH/44XHEEbS+LWqNVGTIk wwJw== X-Gm-Message-State: ANoB5pno2Q1x1HJOh40nIfI7rHsFcRlS9aueFnO8G7gQ7Ri2gac3pBhc hDx+chOcOif6EeSP/oyVVOBZgRyZRbjJL2ri X-Google-Smtp-Source: AA0mqf4WTwovOEfLXXUzq5t4nYSd2m1xaY+qRszJq4sf5q96n/vRYg+qaAZb2iuvRLGaSBON2cAHMQ== X-Received: by 2002:a54:4085:0:b0:35b:a08d:5d71 with SMTP id i5-20020a544085000000b0035ba08d5d71mr20473608oii.173.1670279831699; Mon, 05 Dec 2022 14:37:11 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:73de:6f3c:e63f:58df]) by smtp.gmail.com with ESMTPSA id c6-20020a9d4806000000b0066c15490a55sm8234256otf.19.2022.12.05.14.37.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Dec 2022 14:37:11 -0800 (PST) References: <20221126020452.1686509-1-thiago.bauermann@linaro.org> <20221126020452.1686509-7-thiago.bauermann@linaro.org> 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: Date: Mon, 05 Dec 2022 22:37:08 +0000 Message-ID: <87edtdiijv.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain 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 11/26/22 02:04, Thiago Jung Bauermann wrote: >> @@ -8068,6 +8078,21 @@ remote_target::process_stop_reply (struct stop_reply *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) != nullptr) >> + { >> + stop_reply->arch = gdbarch_update_architecture (stop_reply->arch, >> + stop_reply->regcache); >> + >> + /* Save stop_reply->arch so that it can be returned by the >> + thread_architecture method. */ >> + remote_thread_info *remote_thr = get_remote_thread_info (this, >> + ptid); >> + remote_thr->expedited_arch = stop_reply->arch; >> + } >> + >> struct regcache *regcache >> = get_thread_arch_regcache (this, ptid, stop_reply->arch); >> @@ -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 = find_thread_ptid (this, ptid); >> + remote_thread_info *remote_thr = nullptr; >> + >> + if (thr != nullptr) >> + remote_thr = get_remote_thread_info (thr); >> + >> + if (remote_thr == nullptr || remote_thr->expedited_arch == nullptr) >> + /* 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 recalled this. One deficiency of the current SVE implementation > is that it doesn't have a proper way to hide the Z register when they > don't have any meaningful state (SVE not active, so we have fpsimd > state). I see the SVE_HEADER_FLAG_SVE being checked/set in aarch64_linux_supply_sve_regset and aarch64_linux_collect_sve_regset (though in the latter it is set unconditionally), and also HAS_SVE_STATE being used in aarch64_sve_regs_copy_to_reg_buf and aarch64_sve_regs_copy_from_reg_buf. But I wasn't able to find similar logic regarding hiding the Z registers. Do you have any pointers? > Given the VL will always be reported as > 0, even if there is no > active SVE state, gdb will always attempt to show Z registers. And > those are quite verbose. The VG pseudo-register is defined with an int type, so we could return a negative value to indicate that the Z registers are unused (and the module of the value would still be the vector granule). Would that be ok? > In this sense, the implementations of the the thread_architecture > methods for both native aarch64 and remote differ. While native > aarch64's implementation is capable of detecting the lack of active > SVE state, the remote implementation can't. If gdbserver decided to > drop the Z registers mid-execution (before the SVE state is not > active), there wouldn't be vg for gdb to make a decision. Looking at aarch64_linux_nat_target::thread_architecture my impression is that its result depends only on aarch64_sve_get_vq, so I don't see how it's different from the remote implementation. > I wonder if there is a better way to handle this that would still > allow us to hide these scalable registers when there is no active > state. I guess it depends on whether you would consider using negative VG values as better. :-) -- Thiago