[2/2] Add ARM registers definitions in Monitor commands

Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
 monitor.c |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

Any comments?

Regards,

On 08/02/2013 02:48 PM, Fabien Chouteau wrote:
> Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
> ---
>  monitor.c |   17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/monitor.c b/monitor.c
> index 5dc0aa9..78e93af 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -3167,6 +3167,23 @@ static const MonitorDef monitor_defs[] = {
>      { "cleanwin", offsetof(CPUSPARCState, cleanwin) },
>      { "fprs", offsetof(CPUSPARCState, fprs) },
>  #endif
> +#elif defined(TARGET_ARM)
> +    { "r0",     offsetof(CPUARMState, regs[0])  },
> +    { "r1",     offsetof(CPUARMState, regs[1])  },
> +    { "r2",     offsetof(CPUARMState, regs[2])  },
> +    { "r3",     offsetof(CPUARMState, regs[3])  },
> +    { "r4",     offsetof(CPUARMState, regs[4])  },
> +    { "r5",     offsetof(CPUARMState, regs[5])  },
> +    { "r6",     offsetof(CPUARMState, regs[6])  },
> +    { "r7",     offsetof(CPUARMState, regs[7])  },
> +    { "r8",     offsetof(CPUARMState, regs[8])  },
> +    { "r9",     offsetof(CPUARMState, regs[9])  },
> +    { "r10",    offsetof(CPUARMState, regs[10]) },
> +    { "r11",    offsetof(CPUARMState, regs[11]) },
> +    { "r12",    offsetof(CPUARMState, regs[12]) },
> +    { "r13|sp", offsetof(CPUARMState, regs[13]) },
> +    { "r14|lr", offsetof(CPUARMState, regs[14]) },
> +    { "r15|pc", offsetof(CPUARMState, regs[15]) },
>  #endif
>      { NULL },
>  };
>

On 19 August 2013 09:26, Fabien Chouteau <chouteau@adacore.com> wrote:
> Any comments?
>
> Regards,
>
> On 08/02/2013 02:48 PM, Fabien Chouteau wrote:
>> Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
>> ---
>>  monitor.c |   17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/monitor.c b/monitor.c
>> index 5dc0aa9..78e93af 100644
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -3167,6 +3167,23 @@ static const MonitorDef monitor_defs[] = {
>>      { "cleanwin", offsetof(CPUSPARCState, cleanwin) },
>>      { "fprs", offsetof(CPUSPARCState, fprs) },
>>  #endif
>> +#elif defined(TARGET_ARM)
>> +    { "r0",     offsetof(CPUARMState, regs[0])  },
>> +    { "r1",     offsetof(CPUARMState, regs[1])  },

Rather than adding yet another entry to this target-ifdef
ladder in common code, maybe we can abstract this out to be
a method/field of the CPU object?

Andreas can probably suggest the best approach.

thanks
-- PMM

Am 19.08.2013 10:31, schrieb Peter Maydell:
> On 19 August 2013 09:26, Fabien Chouteau <chouteau@adacore.com> wrote:
>> Any comments?
>>
>> Regards,
>>
>> On 08/02/2013 02:48 PM, Fabien Chouteau wrote:
>>> Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
>>> ---
>>>  monitor.c |   17 +++++++++++++++++
>>>  1 file changed, 17 insertions(+)
>>>
>>> diff --git a/monitor.c b/monitor.c
>>> index 5dc0aa9..78e93af 100644
>>> --- a/monitor.c
>>> +++ b/monitor.c
>>> @@ -3167,6 +3167,23 @@ static const MonitorDef monitor_defs[] = {
>>>      { "cleanwin", offsetof(CPUSPARCState, cleanwin) },
>>>      { "fprs", offsetof(CPUSPARCState, fprs) },
>>>  #endif
>>> +#elif defined(TARGET_ARM)
>>> +    { "r0",     offsetof(CPUARMState, regs[0])  },
>>> +    { "r1",     offsetof(CPUARMState, regs[1])  },
> 
> Rather than adding yet another entry to this target-ifdef
> ladder in common code, maybe we can abstract this out to be
> a method/field of the CPU object?
> 
> Andreas can probably suggest the best approach.

I had similar thoughts when I first saw this patch... I haven't looked
closely into monitor yet though (other than seeing it has too much
target dependencies).

Either a MonitorDef* field (null-terminating the array then) or,
depending on where/how this is used, a method in CPUClass might be
options to better abstract this. Given that there is going to be a
little bit of time before 1.7 now we could take some time to rethink our
design.

A related question that remained unanswered for the Program Counter in
the gdbstub context was whether we want QOM properties for such
registers, which would hint at further abstracting such a register list
to reuse it outside monitor.

Andreas