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

[Maciej W. Rozycki]

On Tue, 12 Jun 2007, Daniel Jacobowitz wrote:

> >  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.

 I will.

> 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.

 Worse yet -- the approach that we have taken is generic.  We can handle 
arbitrary MIPS32/MIPS64 processors as conforming to the current revisions 
of the base architecture specs and the application-specific extensions 
(ASEs) by decoding feature bits defined in cp0 config registers -- there 
four config registers defined so far; additional registers may need to be 
read for variable length register subsets (e.g. watch and performance 
counter registers).

 These in turn may differ between members of the same processor family 
based on configuration of a given system which might be hardwired and/or 
configured from the bootstrap bits.  Further changes may be obtained by 
fiddling with some processor-specific configuration bits, for example in 
some implementations the MMU may be switched between the TLB and the fixed 
mode and this affects some cp0 registers.

 There are only two or three variations that care of specific processor 
IDs from PRId -- all the rest is generic using PRId to determine whether a 
chip is a MIPS architecture or a legacy implementation only.  Using PRId 
as a selector here would be a maintenance nightmare -- there are too many 
of them.

> 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.

 Well, it's actually in mips-tdep.c, so it should work for any MIPS 
target.

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

 I guess this is unfeasible -- there are too many possibilites which are 
neither fixed nor easy to predict as you can see from the above.  Unless 
the XML tags provide means for subsetting the architecture.  Please note 
that to make the matter more exciting the subsets do overlap.

 I shall see how the change fits into gdb in its current state and submit 
the proposal as soon as feasible.

  Maciej