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 654EE3858C50 for ; Thu, 9 Feb 2023 02:46:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 654EE3858C50 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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id CCFCB1E110; Wed, 8 Feb 2023 21:46:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1675910819; bh=onIun/BrpDfzbPnhE7aDV7fYGN7x/USZlZhZgUyhFpw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Z41E7GATYSygrFwnv0CWGEaFQkqmrjMtG+1DTMzwzs3a3s7mNEDJbUoyCzdW9QqGn jEol1t9oUuZQ4DNtvnhdOxvpEb9rLDaTpLehMdft2vHtI+dGH6jTg2Ba0A10G9MAEr 2To5rcY7u8V4UboubArFnr+s0FHQvFTxLn6KWhw0= Message-ID: Date: Wed, 8 Feb 2023 21:46:58 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v3 4/8] gdbserver/linux-aarch64: When thread stops, update its target description Content-Language: en-US To: Thiago Jung Bauermann , Pedro Alves Cc: Luis Machado , Andrew Burgess , Thiago Jung Bauermann via Gdb-patches References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-5-thiago.bauermann@linaro.org> <87pmattzjw.fsf@redhat.com> <7970ac03-1123-d5f6-7b17-808832d43be6@simark.ca> <9a85e2fe-078a-e2ee-7e49-53fe0ceef492@arm.com> <87y1pgaib6.fsf@linaro.org> <3f4e3603-59e3-a896-72e4-d692646c4e44@palves.net> <87v8kd9odi.fsf@linaro.org> From: Simon Marchi In-Reply-To: <87v8kd9odi.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.4 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: > That is, assuming we continue with the thread-specific tdesc approach > rather than the one which expands tdescs to allow describing one > register's type in terms of another one. I'll revisit my notes and think > more about this. Can we expand about this idea? I think I like it, but I don't see 100% how it would work. I can imagine a vector of registers whose size depends directly on the value of some other register that comes before, like: Here, "some_other_register" would be a scalar register that comes before "vec", and whose value dictates directly the number of elements of "vec". But if you wanted to say that the number of elements in "vec" is the value of some_other_register, times 2? I guess we could write: .. but then we get in the realm of defining a grammar, building a parser / evaluator, etc. The type of the vector elements needs to be dynamic too, how do we define that? If the number of possibilities is known and static, we could have some kind of "variant" type, where we list all the possible types, and select among them at runtime based on the value of a preceding register. If I understand correctly, all of this makes it so the size of the response to the g packet will be dynamic too? Simon