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: Sat, 11 May 2002 15:05:20 +0100
- Subject: Re: ARM and virtual/raw registers
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot 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.