Register View bitfields support

Register View bitfields support

[Robert Pîrvu]

Hello,

I am a cdt developer and I'm working on a new functionality for 
Eclipse's Register View.

The current implementation of the Register View does not allow the 
display of individual fields of a register with bitfields. This 
functionality is only available in the Expression view by creating a new 
expression using the “$” and the name of the register.
Register view has a grouping functionality that allows us to create 
custom groups of registers, those groups can be expanded and collapsed 
to show/hide the register in the said group. The same functionality of 
expanding and collapsing can be added to a register with bitfield.

The implementation of this would require the modification of the 
-data-list-register-values MI Command to include a list of registers’s 
bitfields.
And the introduction of a new MI Command 
-data-list-register-bitfields-name, is also needed to retrieve the names 
of the bitfields.

The modified -data-list-register-values would have the following format:

Command: -data-list-register-values [ --skip-unavailable ] fmt [ ( regno 
)*]
Respone:  
^done,register-values=[{number="0",value="0”,bitfields=“{value=0, 
value=0}"}, {number="1",value="{0}”,bitfields=“{[]},...]
Format of the response: [{number="0",value="0”,bitfields=“{[value=0], 
[value=0]}"}]

The --skip-unavailable option indicates that only the available 
registers are to be returned.
The regno option indicates that only the specified register needs to be 
returned. If no register is specified then all registers will be 
returned.
The fmt indicates the format according to which the registers' contents 
are to be returned. Allowed formats for fmt are:

Hexadecimal - x
Octal - o
Binary - t
Decimal - d
Raw - r
Natural - N

If a register doesn't have bitfields, then the bitfields list will be 
empty or it can be not included in the response.

The new MI Command will have the following format:

Command: -data-list-register-bitfield-name [ ( regno )+ ]
Response: ^done,register-bitfield-names=[{name="reg0", bitfields =["C", 
"M"]},{name="reg1", bitfields =["A", "B"]}, ...]

The regno option indicates that only the specified register needs to be 
returned. If no register is specified then all registers will be 
returned.

If the register doesn't have bitfields, then the bitfields list will be 
empty or not included in the response.

Any feedback regarding this feature is greatly appreciated and we are 
open to contribute to its implementation.

Best Regards,
Robert.

Re: Register View bitfields support

[Guinevere Larsen]

On 09/02/2024 13:56, Robert Pîrvu via Gdb wrote:
> Hello,
>
> I am a cdt developer and I'm working on a new functionality for 
> Eclipse's Register View.

Hi!

I'm replying to this mostly so you're not left out to dry, since I'm not 
too familiar with the MI interpreter and I never seen anything like this 
in the CLI interpreter. That said, I do have a few thoughts left inline

>
> The current implementation of the Register View does not allow the 
> display of individual fields of a register with bitfields. This 
> functionality is only available in the Expression view by creating a 
> new expression using the “$” and the name of the register.
> Register view has a grouping functionality that allows us to create 
> custom groups of registers, those groups can be expanded and collapsed 
> to show/hide the register in the said group. The same functionality of 
> expanding and collapsing can be added to a register with bitfield.

My first question is: Does GDB already know of these bitfields? I am not 
sure if it does or not from your description of using Expression View. 
If we already know, having a convenient way to access them sounds like a 
good idea.

If we don't, are they architecture specific? Is the expectation that 
we'd keep that information up to date? Or is this something that should 
(or could) be user-defined? If the latter, the implementation should 
probably come with a way to define them.

Sorry if these questions are very basic, this is pretty far from the 
bits I work on

>
> The implementation of this would require the modification of the 
> -data-list-register-values MI Command to include a list of registers’s 
> bitfields.
> And the introduction of a new MI Command 
> -data-list-register-bitfields-name, is also needed to retrieve the 
> names of the bitfields.
>
> The modified -data-list-register-values would have the following format:
>
> Command: -data-list-register-values [ --skip-unavailable ] fmt [ ( 
> regno )*]
> Respone: 
> ^done,register-values=[{number="0",value="0”,bitfields=“{value=0, 
> value=0}"}, {number="1",value="{0}”,bitfields=“{[]},...]
> Format of the response: [{number="0",value="0”,bitfields=“{[value=0], 
> [value=0]}"}]
>
> The --skip-unavailable option indicates that only the available 
> registers are to be returned.
> The regno option indicates that only the specified register needs to 
> be returned. If no register is specified then all registers will be 
> returned.
> The fmt indicates the format according to which the registers' 
> contents are to be returned. Allowed formats for fmt are:
>
> Hexadecimal - x
> Octal - o
> Binary - t
> Decimal - d
> Raw - r
> Natural - N
>
> If a register doesn't have bitfields, then the bitfields list will be 
> empty or it can be not included in the response.

I think this is a complicated change. I'm not sure how strict we are 
with output consistency, but I think we have to be pretty consistent to 
not break every user of the MI protocol, so adding a new field in this 
return doesn't sound like a great idea to me.

I would suggest adding a new option, --with-bitfields for example, which 
has this output, and leave the default response with the same format.

>
> The new MI Command will have the following format:
>
> Command: -data-list-register-bitfield-name [ ( regno )+ ]
> Response: ^done,register-bitfield-names=[{name="reg0", bitfields 
> =["C", "M"]},{name="reg1", bitfields =["A", "B"]}, ...]
>
> The regno option indicates that only the specified register needs to 
> be returned. If no register is specified then all registers will be 
> returned.
>
> If the register doesn't have bitfields, then the bitfields list will 
> be empty or not included in the response.

When would registers not be included? From the previous paragraph it 
sounds like they'd always be included, and having empty lists make sense.

I don't have any strong opinions on which option is better, just 
commenting on the current explanation. Either way, this can be worked 
out when the implementation itself is being discussed in the patches 
that add it.

>
> Any feedback regarding this feature is greatly appreciated and we are 
> open to contribute to its implementation.

I think this is a cool idea, regardless if these bitfields are 
arch-defined or user-defined. If you show up with patches with an 
implementation for this, I'll be happy to do my best in reviewing them 
(though I can't approve them for merging), otherwise I think the best 
way to go about it is opening a feature request (called Request For 
Enhancement, RFE) on our bug tracker (https://sourceware.org/bugzilla/). 
You can open the bug yourself or I can open for you if you have troubles 
with the account creation process.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
> Best Regards,
> Robert.
>
>

Re: Register View bitfields support

[Robert Pîrvu]

On 2024-02-16 14:00, Guinevere Larsen wrote:
> On 09/02/2024 13:56, Robert Pîrvu via Gdb wrote:
>> Hello,
>> 
>> I am a cdt developer and I'm working on a new functionality for 
>> Eclipse's Register View.
> 
> Hi!
> 
> I'm replying to this mostly so you're not left out to dry, since I'm
> not too familiar with the MI interpreter and I never seen anything
> like this in the CLI interpreter. That said, I do have a few thoughts
> left inline
> 

Hello Guinevere, thank you for the reply :)

>> 
>> The current implementation of the Register View does not allow the 
>> display of individual fields of a register with bitfields. This 
>> functionality is only available in the Expression view by creating a 
>> new expression using the “$” and the name of the register.
>> Register view has a grouping functionality that allows us to create 
>> custom groups of registers, those groups can be expanded and collapsed 
>> to show/hide the register in the said group. The same functionality of 
>> expanding and collapsing can be added to a register with bitfield.
> 
> My first question is: Does GDB already know of these bitfields? I am
> not sure if it does or not from your description of using Expression
> View. If we already know, having a convenient way to access them
> sounds like a good idea.
> 
> If we don't, are they architecture specific? Is the expectation that
> we'd keep that information up to date? Or is this something that
> should (or could) be user-defined? If the latter, the implementation
> should probably come with a way to define them.
> 
> Sorry if these questions are very basic, this is pretty far from the
> bits I work on
> 

As far as I am aware, at the start of the debugging session, GDB already 
has data about the registers such as names, positions, and values. With 
the current format of the -data-list-register-values MI Command, 
bitfields are returned together with the register's value under the 
following format:  value={Register Value In Specified Format,[List of 
Bitfields Names]}.

>> 
>> The implementation of this would require the modification of the 
>> -data-list-register-values MI Command to include a list of registers’s 
>> bitfields.
>> And the introduction of a new MI Command 
>> -data-list-register-bitfields-name, is also needed to retrieve the 
>> names of the bitfields.
>> 
>> The modified -data-list-register-values would have the following 
>> format:
>> 
>> Command: -data-list-register-values [ --skip-unavailable ] fmt [ ( 
>> regno )*]
>> Respone: 
>> ^done,register-values=[{number="0",value="0”,bitfields=“{value=0, 
>> value=0}"}, {number="1",value="{0}”,bitfields=“{[]},...]
>> Format of the response: [{number="0",value="0”,bitfields=“{[value=0], 
>> [value=0]}"}]
>> 
>> The --skip-unavailable option indicates that only the available 
>> registers are to be returned.
>> The regno option indicates that only the specified register needs to 
>> be returned. If no register is specified then all registers will be 
>> returned.
>> The fmt indicates the format according to which the registers' 
>> contents are to be returned. Allowed formats for fmt are:
>> 
>> Hexadecimal - x
>> Octal - o
>> Binary - t
>> Decimal - d
>> Raw - r
>> Natural - N
>> 
>> If a register doesn't have bitfields, then the bitfields list will be 
>> empty or it can be not included in the response.
> 
> I think this is a complicated change. I'm not sure how strict we are
> with output consistency, but I think we have to be pretty consistent
> to not break every user of the MI protocol, so adding a new field in
> this return doesn't sound like a great idea to me.
> 
> I would suggest adding a new option, --with-bitfields for example,
> which has this output, and leave the default response with the same
> format.

This is a good idea, I wasn't aware it was possible to change the output 
format in this way.

> 
>> 
>> The new MI Command will have the following format:
>> 
>> Command: -data-list-register-bitfield-name [ ( regno )+ ]
>> Response: ^done,register-bitfield-names=[{name="reg0", bitfields 
>> =["C", "M"]},{name="reg1", bitfields =["A", "B"]}, ...]
>> 
>> The regno option indicates that only the specified register needs to 
>> be returned. If no register is specified then all registers will be 
>> returned.
>> 
>> If the register doesn't have bitfields, then the bitfields list will 
>> be empty or not included in the response.
> 
> When would registers not be included? From the previous paragraph it
> sounds like they'd always be included, and having empty lists make
> sense.

You're right having empty lists makes more sense than not returning 
anything at all. And I don't think there will be any case in which a 
register would not be returned.

> 
> I don't have any strong opinions on which option is better, just
> commenting on the current explanation. Either way, this can be worked
> out when the implementation itself is being discussed in the patches
> that add it.
> 

Register View uses two MI Commands to populate the view with registers. 
One command which returns the names of the registers, and another one 
which returns the positions and values of the registers. I wanted to 
have a bit of consistency with the commands and that is why I proposed 
to have something similar, one command to return the names of bitfields 
and one for the values. And it will be a lot easier for this to work 
with the existing parsers used by the Register View.

>> 
>> Any feedback regarding this feature is greatly appreciated and we are 
>> open to contribute to its implementation.
> 
> I think this is a cool idea, regardless if these bitfields are
> arch-defined or user-defined. If you show up with patches with an
> implementation for this, I'll be happy to do my best in reviewing them
> (though I can't approve them for merging), otherwise I think the best
> way to go about it is opening a feature request (called Request For
> Enhancement, RFE) on our bug tracker
> (https://sourceware.org/bugzilla/). You can open the bug yourself or I
> can open for you if you have troubles with the account creation
> process.

Thank you again for your feedback. As you advised me I opened a Feature 
Request on the Bug Tracker: 
https://sourceware.org/bugzilla/show_bug.cgi?id=31448 including your 
suggestion with the --with-bitfields option for the 
-data-list-register-values MI Command.