Re: [Qemu-trivial] [Qemu-devel] [PATCH 2/2] Add ARM registers definitions in Monitor commands

["Andreas Färber" <afaerber@suse.de>]

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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg