Re: ARM and virtual/raw registers

[Richard Earnshaw <rearnsha@arm.com>]

> The remote target is more than technically broken.
> 

I'm glad we agree on something then ;-)

> GDB is a slave to the remote protocol.  The remote protocol is what 
> decides the layout of the raw register cache and that cache layout 
> depends on what ever the remote target and GDB once, long ago, 
> co-conspired.  You can't touch the raw registers without breaking GDB's 
> ability to debug a remote target.  The MIPS, for instance, has more 
> remote protocol formats than I've had hot dinners.  Every different MIPS 
> configuration has a different, hard wired, remote protocol register buffer.
> 
> BTW, the reason I mention i387-tdep.c is that I think it is an example 
> of where target side manipulation can go wrong.  The i387-tdep code 
> doesn't just massage values, it instead completly re-orders the register 
> cache so that it contains the registers in i387 stack order.  That, in 
> turn, lead to all sorts of bugs when trying to save/restore the i387 
> registers.  If this were re-implemented today, I think it the register 
> buffer would be would left in i387 save order, instead using 
> register_{read,write} (they were not available at the time).

Having either the debug-info register numbers or a single target impose an 
order on the regcache is broken.  Consider the case where we have two 
target interfaces that need to mandate different orderings; clearly one of 
them must fail.  Similarly, having the debug-info mandate an ordering is 
equally broken -- consider two ABIs which use different numbering in the 
debug info.  Clearly, the only way to solve this is to have mapping 
layers, at least in concept, at each interface.  Then the tdep code is 
free to select any ordering it likes in the cache; typically an ordering 
that will lead to greatest efficiency.

A colleague of mine once commented: "There's very few software problems 
that can't be solved with an extra layer of indirection."  This is clearly 
one that can...

> I think, under your model, this would be flaged as a no-no - there being 
> no technical reason for laying the registers out in a way other than 
> according to i387 save order.

See the WIP code I posted just now.

R.