[PATCH 4/8] regcache: Zero-extend small registers described by a register map.

[Andrew Burgess]

* John Baldwin <jhb@FreeBSD.org> [2021-10-26 14:17:36 -0700]:

> On 10/19/21 9:31 AM, John Baldwin wrote:
> > On 10/19/21 1:36 AM, Andrew Burgess wrote:
> > > * John Baldwin <jhb@FreeBSD.org> [2021-07-14 07:07:37 -0700]:
> > > 
> > > > When registers are supplied via regcache_supply_register from a register
> > > > block described by a register map, registers may be stored in slots smaller
> > > > than GDB's native register size (e.g. x86 segment registers are 16 bits,
> > > > but the GDB registers for those are 32-bits).  regcache_collect_regset
> > > > is careful to zero-extend slots larger than a register size, but
> > > > regcache_supply_regset just used regcache::raw_supply_part and did not
> > > > initialize the upper bytes of a register value.
> > > > 
> > > > trad_frame_set_reg_regmap assumes these semantics (zero-extending
> > > > short registers) as I had misread the implementation of
> > > > regcache::transfer_regset and assumed it zero-extended short
> > > > registers.  In my specific use case (x86 segment registers stored as
> > > > 16-bit values), I need the semantics of zero-extending a register
> > > > value in a smaller slot.
> > > 
> > > I don't claim to know if anyone relies on the old behaviour of
> > > transfer_regset_register, but the change you propose seems reasonable.
> > > 
> > > However, the second paragraph of your commit message really confuses
> > > me.
> > > 
> > > It seems to say that a mistake was made in trad_frame_set_reg_regmap,
> > > and so transfer_regset_register should change, then you just jump to
> > > saying you need the zero extend.  I don't really understand the
> > > connection between all these ideas.
> 
> Here's an updated log message that hopefully is clearer:
> 
>     regcache: Zero-extend small registers described by a register map.
>
>     When registers are supplied via regcache_supply_register from a
>     register block described by a register map, registers may be stored in
>     slots smaller than GDB's native register size (e.g. x86 segment
>     registers are 16 bits, but the GDB registers for those are 32-bits).
>     regcache_collect_regset is careful to zero-extend slots larger than a
>     register size, but regcache_supply_regset just used
>     regcache::raw_supply_part and did not initialize the upper bytes of a
>     register value.
>
>     trad_frame_set_reg_regmap assumes these semantics (zero-extending
>     short registers).  Upcoming patches also require these semantics for
>     handling x86 segment register values stored in 16-bit slots on
>     FreeBSD.  Note that architecturally x86 segment registers are 16 bits,
>     but the x86 gdb architectures treat these registers as 32 bits.

Sorry for the delay, I lost track of this series.

Thanks for the updated message, I think this is clearer.

I still wonder if there could ever a case where, if the type of a
register was signed, we should be sign extending, rather than zero
extending...

...but given that, such a situation must already be broken, I'm
assuming that isn't something that exists today.

As such, and with lack of comment from anyone else, I think this is
good to go.

Thanks,
Andrew