Re: [rfc][4/13] Eliminate read_register: read_register in deprecated_mips_set_processor_regs_hack

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Jun 08, 2007 at 01:27:56PM +0100, Maciej W. Rozycki wrote:
> > (Not sure if this is still required, or if it could be replaced by
> > the new XML register mechanism ...)
> 
>  Well, if the latter provides similar means.  I have extensive changes 
> pending for deprecated_mips_set_processor_regs_hack() and this access 
> definitely has to stay.

In the new GDB scheme for such things, a processor with different
register names should be a different gdbarch.  The XML descriptions
are just one way of specifying a new architecture variant and which
variant to use - there are other ways, too.  I would recommend a look
at remote_read_description, which provides another way that is closer
to what you need here.

It's not a perfect fit, though.  What
deprecated_mips_set_processor_regs_hack could be doing is waiting
until the point where we know the architecture well enough to find the
PRID register contents, and then selecting a variant of the
architecture based on that PRID value.  But we do not know the
register layout yet at the point of target_read_description; we don't
know which registers are provided or how big they are.

I don't have an easy answer for this.  Simplest would be to keep it
local to remote-mips.c (as it currently is), but change how it works;
move it from common_open to a new remote_mips_read_description, fetch
the PRID without going through GDB's register cache at all, and then
create an appropriate target description which specifies the processor
based on the PRID.  It would be nicer if we could make it work for
remote.c too though.

Of course you can also make any remote MIPS targets respond with XML
<architecture> tags :-)

-- 
Daniel Jacobowitz
CodeSourcery