Am 19.08.2013 10:31, schrieb Peter Maydell:
> On 19 August 2013 09:26, Fabien Chouteau <chout...@adacore.com> wrote:
>> Any comments?
>>
>> Regards,
>>
>> On 08/02/2013 02:48 PM, Fabien Chouteau wrote:
>>> Signed-off-by: Fabien Chouteau <chout...@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
