From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id F0dcBble5GNRxC0AWB0awg (envelope-from ) for ; Wed, 08 Feb 2023 21:47:21 -0500 Received: by simark.ca (Postfix, from userid 112) id 0A4061E15D; Wed, 8 Feb 2023 21:47:21 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=EAS560Cx; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id AF67B1E110 for ; Wed, 8 Feb 2023 21:47:20 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 547E6385842A for ; Thu, 9 Feb 2023 02:47:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 547E6385842A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675910840; bh=4CX9M/g+C7vdwKtDcY1EPwSm19gwbMBBsCa1Ssed+EQ=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=EAS560Cxa5mtqbMwwCQ1eYKXXJMF5S0T+a6m9v6pMsm7asSIU/EVc9fwTXRv0KT4u TyA/DaZSbTrqbNOxKLUfR42jOWM5eIxAK/uwyy57RX+ElatRDso5qe9MA09Gu3C/RC 6IPC4NGuGaf5yMiv8cuERYrXymDMnx4c8zkbh+nM= 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 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) 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> In-Reply-To: <87v8kd9odi.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > 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