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

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