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

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

On 21/08/2026 11:39, Craig Blackmore wrote:
>
> 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.
>
Did the possible changes to lval_type get discussed?

Thanks,

Craig

> Hi Simon,
>
> Yes, it is only the location aspect that this implementation cares about.
>
> Thanks,
>
> Craig
>
>> Simon