Re: [PATCH v5 1/1] gdb: Add python support for transforming register unwind values

[Craig Blackmore <craig.blackmore@embecosm.com>]

On 12/08/2026 15:43, Simon Marchi wrote:
> 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.

Hi Simon,

Yes, it is only the location aspect that this implementation cares about.

Thanks,

Craig

> Simon