Re: ARM and virtual/raw registers

[Richard Earnshaw <rearnsha@arm.com>]

> >> Now obviously, in order to do all this correctly the stack-frame groveller will have to record the information as it unwinds the stack in some private data; but creating this information is part of the stack-unwinding process.
> 
> > 
> > Yes.  The arm would need to implement a custom get_saved_register() architecture method.
> > 
> > Rather than normalize the registers on the way in.  Consider normalizing them them on the way out via a pseudo.  Doing this would mean that the raw register wouldn't be directly visible and the layer below regcache wouldn't need to normalize anything.
> 
> [to expand a little]
> 
> Two target side interfaces (at least) don't have mechanisms for 
> re-aranging (normalizing) registers on the way in:
> 	- sim
> 	- remote
> I suspect that at least short term, doing everything on the gdb-core 
> side will be easier.

No, it wouldn't.  Because then the gdb-core side would have to know *how* 
the target was connected.  That is, the normalization function becomes

	f(value,target-vector);

which complicates things vastly.

> Having the very raw data in the cache may also prove better for 
> debugging - both the raw (in cache) and the normalized (via register 
> read/write) formats are available.  Perhaphs also look at the i387 which 
> normalizes things on the way in (and its bug count).

Let me try and clarify the model that I think we have in gdb; maybe that 
will help to explain why I think doing it on the gdb-core side is 
incorrect.

GDB has three main vectors, but only two are interesting in this case (the 
third being the UI).  The target vector is the lowest level, it provides a 
virtual abstraction of the processor -- registers, memory etc and methods 
for recovering/changing their contents and generally manipulating the 
machine (stepping, breakpoints, etc).  The target vector should present a 
substantially uniform view of the processor regardless of the method used 
to connect to it.  Putting it another way, the target vector presents 
substantially the basic programmers' model of the CPU to the debugger.

The gdbarch vector is, effectively, the ABI model applied to that virtual 
machine; it covers the mapping rules that were used by the compiler when 
it produced the machine code for the user's program: procedure call 
standards, layout of record types, symbolic information etc.  It knows, 
for example, when a double for the variable X is in register F0: it 
doesn't want to have to worry about how F0 is being recovered from the 
physical machine -- in particular it doesn't want to know about how that 
might vary across the various target connections -- that's the 
responsibility of the target vector.

As to whether the sim or remote targets can be made to support this model 
cleanly, I'm not to worried about sim -- we can always fix this in 
sim/arm/wrapper.c, the layer that interfaces between gdb and the simulator 
so that it presents the virtual CPU model directly.  I don't know enough 
about remote.c at this time to know what the problems are there, but I 
suspect that this one will be the least of my worries when I want to start 
adding support for the banked registers as well.  However, if these 
targets can't present the processor abstraction cleanly, then they are 
technically broken ;-)

R.