This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: ARM and virtual/raw registers
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Richard dot Earnshaw at arm dot com, gdb at sources dot redhat dot com
- Date: Sun, 12 May 2002 15:19:29 +0100
- Subject: Re: ARM and virtual/raw registers
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot 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.