Re: [PATCH 18/23] plugins: add an API to read registers

[Alex Bennée]

Alex Bennée <alex.bennee@linaro.org> writes:

> Akihiko Odaki <akihiko.odaki@daynix.com> writes:
<snip>
>>> What about if I just key based of gdb_regnum and we accept that that
>>> might break the one heterogeneous system we model today?
>>> 
>>
>> That's the best option in my opinion. gdbstub won't work well with
>> such a system anyway, and fixing it will need something similar to
>> GHashTable. But if I would fix gdbstub for a heterogeneous system, I
>> would add a field to CPUClass instead of having a GHashTable keyed
>> with tuples of CPUClass pointers and register numbers. It should be
>> fine considering that CPUState already has gdbstub-specific fields
>> like gdb_regs.
>
> It would be nice to move all register code into CPUClass to avoid
> repeating ourselves but I suspect that is quite an invasive change for a
> later series. Currently all the CPUClass values are set on init and
> shouldn't really be changed after that otherwise we'll have to start
> messing with locking.

Peter pointed out we can see different register sets for the same
CPUClass but with different features enabled which kills that idea. I've
just sent v2 which re-factors the plugin data a little and stores a per
CPUPluginState hash table.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro