From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 7CDCD3853D58 for ; Mon, 28 Nov 2022 16:36:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7CDCD3853D58 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 04C3E1E0D3; Mon, 28 Nov 2022 11:36:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1669653403; bh=8WkOmdb3H7Tvth1dL3RpfRGZ8VfIcgQ3HxBnwF0rtDI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=O8fCJnZpF9xu8OEiPausn4r/SjbhlbbiUA++ybd3zC+nzDGWUDg3YWYQQ2FHZJeuT 1ArlCOso99a5Q2+G8T83kFEdXjfj9DZsljPBiEPGDFdlml765IJKFM7s1a3d0r6XMY Z2l5vVgLd4e7Omm6yGkB/sRCALKk7MMnr6THkgVU= Message-ID: <5d3ca3ed-df52-444e-1652-99b149137707@simark.ca> Date: Mon, 28 Nov 2022 11:36:42 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v2 6/6] gdb/aarch64: Detect vector length changes when debugging remotely Content-Language: en-US To: Thiago Jung Bauermann , gdb-patches@sourceware.org Cc: Luis Machado References: <20221126020452.1686509-1-thiago.bauermann@linaro.org> <20221126020452.1686509-7-thiago.bauermann@linaro.org> From: Simon Marchi In-Reply-To: <20221126020452.1686509-7-thiago.bauermann@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,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: 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 SVE > vector length during runtime. > > 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. I get this when applying, can you address that? Applying: gdb/aarch64: Detect vector length changes when debugging remotely .git/rebase-apply/patch:164: indent with spaces. "gdbarch_dump: update_architecture = <%s>\n", .git/rebase-apply/patch:165: indent with spaces. host_address_to_string (gdbarch->update_architecture)); .git/rebase-apply/patch:186: indent with spaces. gdbarch_update_architecture_ftype update_architecture) warning: 3 lines add whitespace errors. 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 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? > @@ -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); What happens with threads that are not yet known? Imagine the process starts with SVE == 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. If we don't do a "gdbarch_update_architecture" for it and save it somewhere, we'll never set the gdbarch with SVE == Y, will we? Simon