From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oaQlDsmGfGrbriAAWB0awg (envelope-from ) for ; Wed, 12 Aug 2026 10:44:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1786545865; bh=dtNW4SX2hism6vZ8mYJXpBP/iaKKcJDv/iDcjis43a0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Upeezo3+Pg7GuKpYHkGlNMkpSD0V6HJ2PcNs+ODBPeMPDYX/V4uugHQzXlVblj+FE rzoavvF3fNgO2uARSZJUMXuJU8pY3MKEtL8qz72SDOri+tz4CW4CqDGl0Ol1hOhK4Z zFQv8SzaLEmDuEwuqck1VTs+vOfBOdxmTBaZRYms= Received: by simark.ca (Postfix, from userid 112) id 368AC1E166; Wed, 12 Aug 2026 10:44:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=vFwzcT4i; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A3A941E09B for ; Wed, 12 Aug 2026 10:44:24 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 406904BAE7F2 for ; Wed, 12 Aug 2026 14:44:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 406904BAE7F2 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=vFwzcT4i Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 724F34BA2E38 for ; Wed, 12 Aug 2026 14:43:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 724F34BA2E38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 724F34BA2E38 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786545838; cv=none; b=XXMC70GNeKHy6RpG+tzMuPEHsq9bwIh5qGN4OlKNCPkAUTjO4oy/388NXrVX166UqBOODBYlav/MEBXase6PpCgYzWOqmRLHTKUKho1mMDtCCT0TIybaKee/WeT9jMlPlZAevapG5usOOYvqHz29z8f1BBSNWHUIPISDopWth1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786545838; c=relaxed/simple; bh=dtNW4SX2hism6vZ8mYJXpBP/iaKKcJDv/iDcjis43a0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Auw7kx89tMX7Z6bTBAlB/Z8SgkOggOF07oWPhQ/Vx9L90og7V60norflK/3yTqpXTgJoostuIiUbqSRnlB7L1uaJ+vKWjVlFOIOj5IOelVJxMCzDed7lW82SbuKMbxprx+wl631XqPO0iHI10Kq0eBt/O6mgtDrl+jL9zQ+ld2k= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=vFwzcT4i DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 724F34BA2E38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1786545836; bh=dtNW4SX2hism6vZ8mYJXpBP/iaKKcJDv/iDcjis43a0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vFwzcT4ihW9biVLsc1PjOwhdt6We/twiCu2aXubEnlWuUPLbm5ExpbKm7/iKwMqTe qOzrsgZBSPjkdexR6QptDjzyYEEv17S0v2ujBgE8oVKUfcxqMUUpQGIqD8TL44BJEI gMH8bKKc9+7DIzEDfvKFeoTPA5rj1MYAe92izmb0= Received: by simark.ca (Postfix) id DB3DB1E09B; Wed, 12 Aug 2026 10:43:56 -0400 (EDT) Message-ID: <94197116-e5d5-4c96-9acc-76b72cf544c4@simark.ca> Date: Wed, 12 Aug 2026 10:43:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/1] gdb: Add python support for transforming register unwind values To: Craig Blackmore , gdb-patches@sourceware.org Cc: aburgess@redhat.com, eliz@gnu.org References: <20260520131607.32885-1-craig.blackmore@embecosm.com> <20260608120437.566738-1-craig.blackmore@embecosm.com> <20260608120437.566738-2-craig.blackmore@embecosm.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20260608120437.566738-2-craig.blackmore@embecosm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 6/8/26 8:04 AM, Craig Blackmore wrote: > This patch addresses the scenario where a register value is saved in > some mangled form on the target and gdb does not have sufficient > information to demangle it. > > After getting a register value from an unwinder, gdb will call out to > extension languages to allow the value to be transformed. This avoids > having to write a new unwinder and allows the standard unwinders to be > used. > > This patch adds the python class > `gdb.unwinder.UnwindRegisterValueTransformer` which is the base class > for transformers which provide a `read` method for transforming unwind > register values that have been read. There is no similar support for > transforming values being written back to the target as this was not > something I needed to be able to do. Such support can be added to the > python API in future by supporting a `write` method. Currently writing > back to a transformed register will produce an "Attempt to assign to an > unmodifiable value" error. > > Only one transformer can be registered globally at any one time. > Attempting to register more than one transformer or to any other locus > produces an error. The function for registering transformers takes a > locus to allow other loci to be supported in future. Registered > transformers are stored in a list so that registering multiple > transformers may be supported in future. > > `gdbpy_get_register_descriptor` is now externally visible as it is used > to create a gdb.RegisterDescriptor object to pass to the `read` method. > > This patch adds read-only attribute `gdb.Value.lval_type` which > transformer methods can use to decide to skip modifying values that did > not come directly from the target and may not need transforming, for > example, values taken directly from DWARF. I remember that when discussing DWARF locations on the stack things with Pedro (upcoming DWARF 6 features), and how GDB would implement them, the conclusion was that the lval_type enum was really conflating two things that should be orthogonal. If I remember correctly, I think that it should be two axis: - the location part: where are the bits located (register, memory, nowhere) - the lval-ness: is this a value that can be assigned The details are blurry because it's been a while, and unfortunately Pedro is OOO at the moment. I'd like to have a chat with him about this once he's back, before we expose this concept to Python. It might just be a matter of choosing a future-proof name for the new property. From what I understand, what you care about in the UnwindRegisterValueTransformer implementation is the "location" aspect of it, so perhaps the property name could convey just that, and not the "lval" aspect. Simon